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.