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

[Alan Mackenzie]

Hi, Stefan!

On Mon, Jul 24, 2006 at 04:43:14PM -0400, Stefan Monnier wrote:
> >     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.

OK.

> > 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.

I think I have, in our previous discussion.  I think it's clear that
f-l-multiline properties are erased throughout the change-region, and
have to be recalculated througout the change region, at every change.
For most C-like languages, this will be expensive for large regions.  Of
all the CC languages, you can only determine f-l region boundaries
cheaply in AWK (and maybe IDL).  By contrast, f-l-extend-region only
needs to do the calculation at the two ends of the changed region, and
has to do it just as often.

This extra calculution will delay the display of fresh buffer areas when
scrolling, for example.

> > 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).

Could you be more explicit here, please, on what these alternatives are?
I've not been aware of them up to now.

[ .... ]

> >     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?

I don't think we should be so casual about other people's processor
cycles.  The performance difference will be very noticeable if Emacs ever
comes to be run on application servers rather than individual desktops,
for example.  If "public Bar" were a 20-line declaration, the delay might
well be noticeable, especially on the sort of older PC's which still
permeate the developed world.  ;-)

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

> Same as 99% of the languages supported by Emacs.

Well, there's shell-script, AWK, Fortran, Makefiles, ....  But giving the
99% of languages a method to fontify syntactic units rather than crude
single (or multiple) lines can't be a bad thing.

> > 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.

Oh, tell me all about it!  ;-)  But there's a lot of stuff which isn't
CPP in a typical C buffer.

> > 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.

Indeed, not.  But doing our stuff in a way that obfuscated C works right
at no extra cost is not a bad way to go.

>         Stefan

-- 
Alan.