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

[Stefan Monnier]

> C preprocessor on Javascript like we do).  Rigid parsers with nonterminals
> and error productions appear  superficially attractive, but using them for
> all aspects of a mode not  only leads to the issues you discuss below, but
> also prevents that  mode from being reused for similar languages without the
> grammar being  re-worked. It's the wrong approach.

I've had a fairly long exchange with CEDET's author several years ago,
where I made a similar point.  I clearly fully agree: indentation should
work backward from the indentation point and look at as little of the
buffer as possible.  This ensures that if some weird thing is going on
elsewhere in the buffer, it won't interfere.

IOW, the parsing infrastructure (currently limited to syntax-tables and
Lisp) should be able to parse backwards.  I'm leaning towards
operator-precedence-grammars for now.

> enough to warrant the terrible backward  compatibility problems that would
> be generated by a switch to overlays.

The problem is performance (and no, it's not intrinsic to overlays, but
it's what we have, so until someone revampts the implementation it's
what we have to live with).

> That other programmers have resigned themselves to inferior
> fontification is no argument for Emacs to accept it.  Asynchronous
> fontification is completely unacceptable for me, and if it were to
> become commonplace and unavoidable in Emacs, I would simply stay with
> older versions.

I partly agree.  I imagine that it'd be OK for the fontification to take
place in 2 steps: one part on-the-fly and another part with a delay
(this other part could be a refinement which could include
warnings/error messages, but also updates to other parts of the code).


        Stefan