I do not know if anyone asked you about that already, but was tighter scripting integration via MacRuby (or Lua) ever considered for TM2?
Since I can see half of the bundle scripts (these doing heavier work) are Ruby already, I can see that integrating with MacRuby could bring potential benefits: (1) persistent memory structures, each bundle could possible create some class storage variables, i.e. keep there autocompletion information (2) TM2 could expose more dynamic API to the scripts: hooks, callbacks (3) direct access to the editor buffer & GUI elements, exposing scope tree to the scripts (3) scripts running via MacRuby could use all Cocoa API, making life easier for other apps integration, i.e. via AppleScript (4) many (most?) of the work now done by TM2 core could be offloaded to the bundles and its developers, so TM2 itself could be just set of classes driven by MacRuby scripts (5) possible to make more advanced autocompletion for various languages, thanks to (1) (2) (3)
But also I can see potential problems: (1) no compatibility with TM1 (but anyway TM2 is about to be free upgrade to TM1, and also superior to its predecessor) (2) bundle script can hog TM memory, and also hang TM, more discipline is needed for such scripts, but TM2 could supervise such scripts and kill them if necessary (similar way the browsers do with JavaScript) (3) potential class namespace collisions, but then each bundle could possibly run inside its own MacRuby environment (4) TM2 would need to bundle some version of MacRuby.framework
Regards,
On 9 Jan 2012, at 10:58, Adam Strzelecki wrote:
I do not know if anyone asked you about that already, but was tighter scripting integration via MacRuby (or Lua) ever considered for TM2?
Since I can see half of the bundle scripts (these doing heavier work) are Ruby already, I can see that integrating with MacRuby could bring potential benefits: (1) persistent memory structures, each bundle could possible create some class storage variables, i.e. keep there autocompletion information (2) TM2 could expose more dynamic API to the scripts: hooks, callbacks (3) direct access to the editor buffer & GUI elements, exposing scope tree to the scripts (3) scripts running via MacRuby could use all Cocoa API, making life easier for other apps integration, i.e. via AppleScript (4) many (most?) of the work now done by TM2 core could be offloaded to the bundles and its developers, so TM2 itself could be just set of classes driven by MacRuby scripts (5) possible to make more advanced autocompletion for various languages, thanks to (1) (2) (3)
I think this is the philosophy redcar editor has adopted, but this is based on jruby to be cross platform.
Dave.
But also I can see potential problems: (1) no compatibility with TM1 (but anyway TM2 is about to be free upgrade to TM1, and also superior to its predecessor) (2) bundle script can hog TM memory, and also hang TM, more discipline is needed for such scripts, but TM2 could supervise such scripts and kill them if necessary (similar way the browsers do with JavaScript) (3) potential class namespace collisions, but then each bundle could possibly run inside its own MacRuby environment (4) TM2 would need to bundle some version of MacRuby.framework
Regards,
Adam Strzelecki
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 09/01/2012, at 17.58, Adam Strzelecki wrote:
I do not know if anyone asked you about that already, but was tighter scripting integration via MacRuby (or Lua) ever considered for TM2? […]
Never know what to answer when people ask if X was considered: I have lots of thoughts on most issues, that probably counts as “having considered it” but is a rather useless answer.
I see both downsides and upsides about tight scripting integration. It has to be done very carefully and really be thought through, not rushed or done ad hoc — I still think opening up TM for tight integration is too early — some of it also relates to internal data structures used in TM, e.g. ensuring good simple APIs can be provided that still provide good scalable performance etc.
On Mon, Jan 16, 2012 at 03:33, Allan Odgaard mailinglist@textmate.org wrote:
On 09/01/2012, at 17.58, Adam Strzelecki wrote:
I do not know if anyone asked you about that already, but was tighter scripting integration via MacRuby (or Lua) ever considered for TM2? […]
Never know what to answer when people ask if X was considered: I have lots of thoughts on most issues, that probably counts as “having considered it” but is a rather useless answer.
I see both downsides and upsides about tight scripting integration. It has to be done very carefully and really be thought through, not rushed or done ad hoc — I still think opening up TM for tight integration is too early — some of it also relates to internal data structures used in TM, e.g. ensuring good simple APIs can be provided that still provide good scalable performance etc.
For what it's worth, I like the fact that TM is missing any "tight" integration. All commands are basically (more or less glorified) executable scripts that get fed some input from TM and feed some output back to TM for interpretation (i.e. filters), making TM the most UNIXy editor available on the Mac.
And I consider that a plus, but then again I'm a bit weird :-)
Cheers, Martin
On 16/01/2012, at 16.01, Martin Kühl wrote:
[…] I like the fact that TM is missing any "tight" integration. All commands are basically (more or less glorified) executable scripts that get fed some input from TM and feed some output back to TM for interpretation (i.e. filters), making TM the most UNIXy editor available on the Mac.
And I consider that a plus, but then again I'm a bit weird :-)
It’s definitely a big plus — makes the commands simpler and allow them to be used in new ways, for example there is nothing preventing them from being run on a file browser selection, perhaps having the user specify a glob (like *.php) before running the “Strip Whitespace” command recursively on selected folders or similar.
Sort of same principle with grammars and snippets; the less the customizations know about the host environment, the more we can extend the way they are used in the future. The minute we do the two-way tight integration, we paint ourself into a corner and often also raise the barrier to entry because users have to learn about TextMate API to make even simple things.
So definitely I want to pursue the current decoupled/declarative/unixy approach whenever possible — tight integration I think is more likely to happen via a plug-in API — this also avoids having to favor a particular scripting language (but instead do C bindings).
So definitely I want to pursue the current decoupled/declarative/unixy approach whenever possible — tight integration I think is more likely to happen via a plug-in API — this also avoids having to favor a particular scripting language (but instead do C bindings).
It is clear to me now. Thanks.
Regards,
On 2012-01-16 04:01, Martin Kühl wrote:
And I consider that a plus, but then again I'm a bit weird :-)
I also consider it a plus. And I'm not weird, just very opinionated. :-)
What I would consider ideal would be for all editor functions to be exposed via an interface usable by any language. Perhaps when run by TM, commands would get a fourth open file descriptor that could write commands to and read output from TM. Or perhaps TM could create a Unix-domain socket or named pipe that anything could read and write. Or perhaps it could expose AppleScript objects. Yes, I said it. AppleScript. I never touch the stuff myself, but there are bindings so you can use AppleScript objects from any real scripting language. If nothing else, the 'osascript' shell command can be run.
Longing for the Good Ol' Days of Amiga apps with AREXX ports...
That would lose my main reason for using TextMate - that it lets bundle writers choose what language they want, from bash to php, rather than bolting them into one choice they might not know or like.
Another editor does this, but I like TextMate's openness.
Best, tim
On 9 Jan 2012, at 03:58, Adam Strzelecki wrote:
I do not know if anyone asked you about that already, but was tighter scripting integration via MacRuby (or Lua) ever considered for TM2?
Since I can see half of the bundle scripts (these doing heavier work) are Ruby already, I can see that integrating with MacRuby could bring potential benefits: (1) persistent memory structures, each bundle could possible create some class storage variables, i.e. keep there autocompletion information (2) TM2 could expose more dynamic API to the scripts: hooks, callbacks (3) direct access to the editor buffer & GUI elements, exposing scope tree to the scripts (3) scripts running via MacRuby could use all Cocoa API, making life easier for other apps integration, i.e. via AppleScript (4) many (most?) of the work now done by TM2 core could be offloaded to the bundles and its developers, so TM2 itself could be just set of classes driven by MacRuby scripts (5) possible to make more advanced autocompletion for various languages, thanks to (1) (2) (3)
But also I can see potential problems: (1) no compatibility with TM1 (but anyway TM2 is about to be free upgrade to TM1, and also superior to its predecessor) (2) bundle script can hog TM memory, and also hang TM, more discipline is needed for such scripts, but TM2 could supervise such scripts and kill them if necessary (similar way the browsers do with JavaScript) (3) potential class namespace collisions, but then each bundle could possibly run inside its own MacRuby environment (4) TM2 would need to bundle some version of MacRuby.framework
Regards,
Adam Strzelecki
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Jan 18, 2012, at 7:30 PM, Timothy Bates wrote:
That would lose my main reason for using TextMate - that it lets bundle writers choose what language they want, from bash to php, rather than bolting them into one choice they might not know or like.
Another editor does this, but I like TextMate's openness.
Seconded.
Gerd
-
Adam Strzelecki -
Allan Odgaard -
Dave Baldwin -
Gerd Knops -
Martin Kühl -
Steve King -
Timothy Bates