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

[Alan Mackenzie]

Morning, Stefan!

On Tue, Aug 01, 2006 at 03:23:54PM -0400, Stefan Monnier wrote:
> > It seems that the identification of the "safe place" (in a previously
> > unfontified region) needs to be done by a function essentially the
> > same as font-lock-extend-region-function, since f-l-multiline
> > properties haven't yet been applied.  In that case, what is the
> > advantage in using f-l-multiline at all?

> As opposed to using what?

As opposed to using (c-font-lock-expand-region BEG END OLD-LEN) called
from \(font-lock\|jit-lock\)-after-change, and also (as we thrashed out
some while ago) from font-lock-default-fontify-region.

Stefan, was that question of yours really needed?  After the substantial
amount of discussion we've had over the issue in the last few months, was
it not clear exactly what I meant?  I've been feeling frustrated at your
posts on this topic for a long time, in that you don't seem to be
carrying the context of one post forward to the next.  This means I've
got to keep restating the basis of the discussion time after time and
this makes constructive dialog very wearisome.

> Remember f-l-multiline is about /rehighlighting/.  Think of it as
> *de*highlighting.  I.e. find the places where there used to be a
> multiline element but not any more.

The f-l-multiline mechanism forces a distinction between the first
fontification and subsequent fontifications, a distinction which didn't
previously exist.  This is surely a Bad Thing, suggesting that f-l-m is
suboptimal.

> > It's going to be more code.  Might it, for example, be faster?

> It's expected to be faster than recomputing this extended region in
> before-change-function (since it's the only place where you can do it
> otherwise: in after-change-function it's too late (unless you saved the
> info somewhere) because the buffer text may not contain the pertinent
> info).

I think your logic is flawed there.  Certainly calculations will need
doing in before-change-functions, for the reason you give.  But it is not
clear that MORE calculation has to be done, rather that it has to be done
in a different place.

> >> > Maybe you're right here.  But care would be needed to ensure that
> >> > there is some boundary between adjacent f-l-multiline regions,
> >> > such as in this sort of thing:

> >> >         foo =
> >> >         3 ;bar =
> >> > /*        ^^ */
> >> >         4 ;

> >> Yes, that's a problem.  I don't even think the current code handles
> >> it right.

> > Again, this problem doesn't happen with the
> > f-l-extend-region-function approach.

> [ Not sure what you mean by f-l-extend-region-function, BTW.  Is it the
>   current f-l-extend-region-function in Emacs-CVS, or is it some future
>   thingy that will be called from f-l-refontify-region?
>   The current f-l-extend-region-function can't help with
>   /identification/ any more than f-l-multiline. ]

I mean the function that will be called with parameters BEG, END, and
OLD-LEN from \(font\|jit\)-after-change-function, and also the same (or a
similar) function that will need to be called from
font-lock-fontify-region, as you pointed out back in ?April.

[ .... ]

> > When you load that file (having stripped the leading "> >>" from each
> > line ;-), only the first 8 "defined"s get fontified.  (Up to byte 500
> > (jit-lock-chunk-size), perhaps?)  If you set font-lock-support-mode
> > to nil, the whole caboodle is (at least to begin with) fontified
> > right.

> I.e. it's a problem of /identification/, so of course f-l-multiline won't
> help you.

So a font-lock-extend-region-function is needed for a buffer's very first
fontification.  Do you agree?

This function could determine the region for future fontifications
equally well, too.  So it would seem that applying font-lock-multiline
properties is redundant - UNLESS doing so has some other benefit, such as
reducing the amount of computation.

> > The point I was trying to make was that locating the "safe place" can
> > be a long-winded slow operation - that in a piece of code like the
> > above (which isn't untypical), the strategy of placing f-l-multiline
> > properties might cause this expensive analysis to be done several
> > times per buffer change.

> I don't understand: the costly operation to find the safe place is what
> you need for /identification/.  Once you've done that, the
> f-l-multiline property allows you to store the resulting info (which
> you computed for /identification/, not for f-l-multiline) so you won't
> have to recompute it later when deciding what to dehighlight.

In the current f-l-m approach, the f-l-m properties are erased and
recalculated after every fontification:  the _identification_ is done
repeatedly.  (Is there any fundamental reason for this?  Would it not be
possible and better to allow the major mode code to decide when to
recalculate them?)  I think you're assuming that recalculating f-l-m
properties can be done as a cheap side effect of applying faces.  I'm not
at all sure this is the case.

-- 
Alan.