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

[Lennart Borgman <lennart.borgman@gmail.com>]

On Tue, Aug 11, 2009 at 12:06 AM, Eric M. Ludlam<eric@siege-engine.com> wrote:

Hi Eric,

>  The concept of using the Semantic parser/generator framework for
> improving font-locking accuracy has come up many times.  No-one to my
> knowledge has attempted to mix the two.


Maybe that can easier be done if Semantic parser use
font-lock/JIT-lock timers and marking to keep track of what need to be
reparsed? (It is just a wild idea perhaps.)


>  The CONS are that everything in Semantic is set up to parse the entire
> buffer in one pass, and to parse logical sub-sections only after a full
> parse has been done.


So you do a first pass with coarse parsing and then you look in the
sub-sections for details? Is this strictly necessary? I guess you are
looking for top level definitions in the first pass?

Could that pass have its own state and continue upon demand (when an
item is not recognized) or is such a logic impossible?

(I guess font-lock/JIT-lock could be improved to help with keeping
track of what parts of the buffer that have been parsed/maybe
fontified.)


>  I would imagine that the parsing engine in Semantic, if it is deemed
> critical by the maintainers, will get faster if key components are
> integrated into the C code.

Is that part stable?


> I would imagine a font-lock replacement
> could be implemented fairly easily, but getting it to work as quickly as
> font lock would take a fair effort.

Maybe a cooperation would be better.


>  Lastly, as David Engster stated, CEDET has decoration tools that
> decorate entire tags in some way, such as putting a line on top of
> functions.  This is a separate decoration activity not related to font
> lock, and something font lock would not be able to do reliably.

Why not if it asks the parser?


> Enjoy
> Eric