[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Colascione
Subject: Re: "Font-lock is limited to text matching" is a myth
Date: Tue, 11 Aug 2009 11:06:55 -0400

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

Daniel Colascione <address@hidden> 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]