Re: address@hidden: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

>     Date: Sun, 30 Apr 2006 12:48:36 +0000 (GMT)
>     From: Alan Mackenzie <address@hidden>
>     Reply-To: Alan Mackenzie <address@hidden>
>     To: address@hidden
>     Subject: font-lock-extend-region-function: Final refinements.

> It hasn't as yet been installed, although it would establish the
> infrastructure with which the problems being discussed here could be
> wholly and efficiently erradicated, without resort to obscure coding.

Richard put it on the backburner, claiming he hasn't seen the other thread
where you presented your point of view and then I presented mine.  We need
to start it over, but I've had other horses to flog.

> I know what your paragraph refers to.  We've discussed it at great
> length already, and I think I understood it at the time you posted it.
> That approach is more obscure and more inefficient (in terms of
> processor cycles) than anything I want to put into CC Mode.

You haven't shown any evidence of inefficiency.

> Is there any chance of you adapting the font-lock-multiline mechanism so
> that the properties can be applied _before_ fontification, exactly where
> they are needed, rather than _after_ fontification throughout the entire
> change region?

That's the thing on the backburner.  But it's still unrelated to the OP's
problem which was specifically about *re*fontification, where the
current font-lock-multiline support is all you need (and if you don't like
it, there are already several existing alternatives, see the lispref
manual).

I.e. you need both to be able to extend the region just-before fontification
(to do the initial discovery of multi-line elements) and to re-extend the
region based on info kept from the last fontification (to properly
refontify such elements).

>> > I also dislike being unable to specify an exact fontification region
>> > to Font Lock (such as the bounds of one of Simon's comments).

>> I don't understand what you're referring to.

>> From Simon's example:

>     public Bar    // Bar fontified as a type, at first

> type a space after "first".  The region I want to specify to Font Lock
> is exactly this:

>     public Bar    // Bar fontified as a type, at first 
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Oh, I see.  It seems very minor.  Why do you care?  Is the performance
difference ever noticeable?  If yes, how often?

> Most of CC Mode's languages are not line-based.

Same as 99% of the languages supported by Emacs.

> I think it's unhelpful to construe it's font-locking stuff in terms of
> buffer lines.  This is what has led to many complaints about font locking
> in CC Mode (many of which have appeared directly in bug-cc-mode).  If CC
> Mode can specify a font-locking region based on language constructs
> (e.g. a whole statement, a comment, a string, a declaration), these
> problems will go away.

Thanks to CPP and other preprocessors, there will always be cases you
can't handle.

> Even entries to the obfuscated C competition would
> get correctly and efficiently fontified.

I don't see why we should waste our time trying to handle that correctly.


        Stefan