On 14. Feb 2007, at 01:52, Juan wrote:
The point it is impossible to build a recursive scope in HTML. In HTML, for example, if your are inside a nested tag and you press ^- Opt-B one time, to times, three times, etc, you will get _all_ your source selected. Never at the third (etc) level out in the nesting.
That has to do with how the grammar has been made, i.e. it does not mark up a tag pair as its own element, and thus cannot be selected via ⌃⌥B -- something we do consider improving (in the HTML grammar). At least it will be updated for the 2.0 grammar features.
I like a lot TM, I can assure you, for many reasons. But I don't understand why the main problems are so tabued.
They are not -- but you seem to have just the one goal of repeating the need for an API, but without being concrete in what you need from it.
The need for an API has already been acknowledged, but there are a lot of considerations before opening up the innards of TM. Embedding a Ruby interpreter and implementing a carbon copy of Alpha’s API (as what seems to be your suggestion) is certainly not how I want to tackle it.
You also overlook the power of declarative abstractions, which is one of the fundamental advantages in TM. Solving problems with code is often counterproductive to finding new and better abstractions, and the abstractions, when done right, buys you much more long-term.
Example: TextMate uses a declarative system for language grammars, some people have pointed out limitations in this system which would not exist if each bundle author could just write his own parser. But if you look at how many languages TM support, and how good it actually does support them, you should find that TM generally does a *much* better job than competing editors with binary parsers -- not only that, but because everything is declarative, one grammar can easily include another, and 2.0 will be able to use existing grammars for completely new features, like the scope injection mentioned on this list. This would be *completely* impossible, had each bundle author written his language parser as code.
So there is no taboo -- when people are not jumping on the bandwagon it is likely because they do not think that it is as serious a problem as you make it out to be. Adding an API gives us a little more power, adding new abstractions (like attributes and dynamic scopes) will give us a lot! Did HTML gain the most from CSS or JavaScript? While they are different things for different purposes, the CSS abstraction IMO added immensely more value to crafting web pages.
Another thing I should mention: The way you open up a Mac application for scripting is via the Open Scripting Architecture, yes, AppleScript is slow and just plain sucks. But wait, isn’t there a lot of rumors about RubyOSA, PyObjC, etc. being included in Leopard? Maybe we should hold off embedding that Ruby interpreter, and see if using the platform-recommended way will not give us more long-term advantages ;)
DISCLAIMER: Don’t read too much into the above, I am still evaluating.