On Jan 25, 2005, at 20:44, Chris Thomas wrote:
AS integrates with other applications which one may use in combination with TextMate, like Automator, Script Editor [...]
Also a point I forgot to mention, AS has been refined over many years to be an application extension language, this means it has stuff like event handlers [...]
What capabilities are you referring to? I mean, there's no functional difference between: [...]
You're right. In my mind I had made this out to be much more than it actually is (a callable function).
So I partially take back the thing about AS being the answer. AS (or apple events) will definitely be the first thing used to expose the editor API, which should allow the editor API to be called in most scripting languages.
But for callbacks I'm not sure AS makes sense with the current anti-AS attitude of TextMate (and AS just being crappy for the things you'd normally do in a callback/user function).
I see a few possibilities:
One (easy to achieve) solution is to run a script using bash, as currently done with commands, but give it arguments and probably re-use the environment space for all callbacks made for/from the same buffer. This script could be written in whatever language the user desires and would use normal environment variables for state (across invocations), gets its argument as the script arguments, and use the osascript command if it needs to talk to the editor (or an AE extension/binding, as the RubyAEOSA Chris linked to).
I think this gives maximum flexibility -- it does have syntactic overhead when 1) investigating script arguments, 2) talking with the editor, and 3) needing to read/write persistent (i.e. across invocations) variables (and generally a sub-optimal solution for storing such info, since it needs to be serialized into environment variables). #1 and #3 also exists for CGI scripts.
The other extreme is to embed a scripting language interpreter into TextMate, extend this language so that it can communicate with TM (i.e. w/o going through osascript -- like e.g. exposing TM settings as an {associative array|map|dictionary|hash}, adding commands like move_caret etc.), and simply let callbacks be functions (written in this scripting language) -- TM could scan scripts for event handlers and automatically establish the callbacks when the script is somehow added to TM.
I do however prefer not to choose a specific language, which is why I currently do lean a bit toward the shell solution, which, despite the more verbose syntax for the 3 things mentioned, is probably easier for most to use, since they would not need to learn a new language (but could choose their own, exactly as with CGI/apache) -- and I guess one could create TextMate bindings for most languages, similar to what's currently done for Cocoa.
Another solution (which could simply be in addition to the shell solution) would be to have TM delegate all scripting stuff to a plugin, and the 'embedded language' would lie entirely in this plugin. That way it would appear as if the embedded language was Python, Ruby, etc. (and the user could select which plugin to handle the callback on a case-by-case basis (or plugins would automatically be chosen based on script extension)).
The problem with supporting several languages is that the editor API may have to be lowest denominator (i.e. procedural) -- but if OO is required I could probably make the API so that OO wrappers could be more or less auto-generated based on naming/arguments (probably at run-time by the script plugin).
hmm... I'll need to give this some more thoughts -- though this is not something I plan to do over the next weeks, so there's plenty of time, and I'm just thinking out loud here! :)