Re: "Font-lock is limited to text matching" is a myth

[Daniel Colascione <danc@merrillpress.com>]

On Aug 11, 2009, at 10:50 AM, Chong Yidong wrote:

> Daniel Colascione <danc@merrillpress.com> writes:
>
>>> There is a relatively simple alternative that might appease Daniel:
>>> I could have js2-mode simply not do any highlighting by default,
>>> except for errors and warnings.  We'd use whatever highlighting is
>>> provided by espresso-mode, and users would be able to choose between
>>> espresso-highlighting and js2-mode highlighting.  With the former,
>>> they'd get "instantaneous" font-locking, albeit not as rich as what
>>> js2-mode can provide.
>>
>> That's an interesting idea, but my concerns are not limited to js2-
>> mode's highlighting.
>
> You don't properly elaborate what these additional concerns are.

I thought I discussed them well enough in the remainder of the  
message, but I'll summarize them here:

- full parsers belong in the CEDET infrastructure where they can be  
accessed via a common API
- if this API is not rich enough, it ought to be extended
- normal major modes shouldn't rely on rigid grammars because that  
makes them brittle. Anything that needs such a grammar should be an  
optional and preferably generic minor-mode

(I still think it'd be worthwhile to include the JS2 parser in CEDET,  
which supports parsers not necessarily generated with wisent or bison.  
It seems robust in its problem domain.)

> I don't use either mode, but from reading the discussion it seems to  
> me
> that the optimal solution is to use espresso mode's code for font-lock
> and indentation, and js2-mode's code for the commands that need to be
> better aware of semantic information (show/hide elements, error
> reporting, marking defuns, etc.)

That could work, but keep in mind that espresso already has a fairly  
robust and substantial parsing system that doesn't rely on a full  
grammar, and that can still reliably mark functions and generate  
multilevel imenu structures.

In terms of featureset, I don't see the differences between (espresso 
+CEDET+some-sort-of-flymake-lint) and (js2) to be very large, though  
what differences there are should certainly be dealt with in whatever  
ends up being the default for Javascript.

>> There is *already* a separate and optional full parsing framework
>> called CEDET that is powerful, generic, and not tied to a major-mode
>> in particular. The right approach is for a given major-mode to
>> understand enough of a given language for fontification and
>> indentation while leaving more substantial parsing and indexing to
>> CEDET (which the user can disable). I recognize that js2's parser may
>> work well in its problem domain --- couldn't it just be added to
>> CEDET?
>
> I don't think this is a necessary condition.  We can freely move the
> code around the Emacs tree once it's already in there; what's more
> important is to have something working.

We already have not one, but two working solutions. And granted, I'm  
not a core developer, but from where I'm sitting it seems code is  
seldom moved around once committed.