[TxMt] "embedded" interpreter. Was: Quick find and open last closed file

[Jacob Rus]

Juan writes, about a 'built-in interpreter':
> I have been working with an editor with built[-in] interpreter for  
> more than ten years.  I understand what you say about Emacs [...]
> 
> Of course, I recognize TM has inside very clever design and more  
> important, it is really MacOS friendly and it is very well integrated  
> in the system exploiting everything in the system and using the  
> cleverly the most important frameworks.
> 
> But ¡there are so many things that depends on having an EI, embedded  
> interpreter, that the extensibility of TM is braked and will need a  
> lot of extra efforts for reaching the half of the goals.
> 
> The examples I gave to you were only a few and can grow fast.  There  
> are many others [...] all of them impossible with the TM model except  
> that in future versions TM hard-coded them and gives us direct access  
> by new tricky interface gadge[t]s.
> 
> TM needs an internal well organized dictionary of methods for  
> accessing its state and an internal language for building in-memory  
> structures.  These both things doesn't have anything to do with the  
> external scripting calling ability.  Is my opinion.

The thing is, I find the types of interactions supported by TextMate's "tricky
interface gadgets" much more useful than the complex and varied interactions
commonly used in editors such as emacs which allow in theory any behavior
whatsoever.

While it is undoubtedly true that what you call "embedded" scripting is very
powerful, and enables a user to do things otherwise impossible, the other result
is that each user ends up re-inventing these interactions for themselves.  And
in the end, every language mode has a completely different style of interaction,
which must be learned separately.  These language modes are extremely difficult
for regular users to modify or extend, because each one has its own
architecture.  To create their own modes, users need to have a deep
understanding of the editor's metaphors and API.  And interactions are brittle;
small changes can break functionality in confusing ways.

TextMate has a different model.  Instead of giving users a single entry point to
customization in the form of a scripting language with a large API, Allan has
taken a hard look at the types of editing patterns common to many languages, and
designed flexible systems for *easily* building up functionality to meet those
needs.

A simple TextMate language grammar, with far more granular control than any
other editor I've seen, can be created in the course of an afternoon by a
complete newcomer, with a tiny bit of help from a more experienced user. 
Snippets and macros which are immediately useful can be created by anyone who
spends the 20 minutes to read the relevant sections of the manual.  In the end,
a bundle contains several discrete parts, which can be reused easily in
different contexts, which can be changed independently of one another, and which
are very transparent for even users unfamiliar with TextMate.

So, while I think TextMate will likely eventually get some more hooks for
commands (or whatever structures Allan provides in the future) to interact with
the application--something akin to the embedded interpreter you're talking
about, though hopefully not tied to any specific language--until that day, we
still have what I consider the most capable text editor.

I suppose what I'm trying to say is: take a look at the screencasts, try out the
existing bundles, read the TextMate manual, and learn about the capabilities
which are already available, before complaining about interactions which aren't
yet possible.  With a month or two of solid TextMate experience, I imagine your
approach to solving your eding problems will have changed somewhat to align with
TextMate's mechanisms.  You might surprise yourself, and find that what exists
is more powerful than what you think you want now.

If you have specific use cases, people on this list or in the IRC channel will
be happy to discuss possible methods for accomplishing what you want.  If there
are new types of automation that would be a significant aid to a large number of
users, I'm sure Allan wants to hear about it.

* * *

All that said, I myself am with you: we users and bundle developers will always
be happy for *more* power.  So I can't wait to see what Allan cooks up for
TextMate 2.

Cheers,
Jacob