[TxMt] Embedded scripting language (was: TM & UBB code some questions)

[Allan Odgaard]

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! :)