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