Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Let's say your identification function (called from f-l-d-fontify-region)
is named c-font-lock-expand-region.  Then calling this function from
f-l-after-change won't do you much good because:
- you've already solved the problem of identification (and f-l-after-change
  is not a place where you can solve the problem of identification anyway).
- the problem of rehighlighting (which amounts to figuring out which part
  of the buffer *used to be* a multiline element) needs to look at the
  buffer *before* the change, not after.

> Stefan, was that question of yours really needed?

Yes, the details matter, and it was very much unclear to me what were
your assumptions.

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

Actually, the distinction has always been present: it's the distinction
between highlighting and dehighlighting.

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

Well, no, not really:
Actually, the calculations can happen at any time between the highlighting
and before-change-function.  With font-lock-multiline, the "calculation" is
done while highlighting (because at this point you already have the info
necessary so no extra real calculation is needed).  Then this info is saved
(in the form of the font-lock-multiline text-property) to be used after
the change.

> 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.  In my experience, adding the font-lock-multiline
property while highlighting has *never* required any significant
extra calculations.  The examples I've shown (in cc-awk.el and cc-fonts.el)
have been pretty typical in this respect.

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

As mentioned above, I can't see how those two functions could be the same
(or similar) and yet both be useful.

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

Yes.  It's now even in Emacs-CVS under the name
font-lock-extend-region-functions.

> This function could determine the region for future fontifications
> equally well, too.

Yes, it could be used in a before-change-function as well.

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

Indeed.
[ Modulo the fact that if you don't have an identification function, you
  may still be able to use the font-lock-multiline property to properly
  handle those multiline elements which you happen to identify somehow.  ]

> I think you're assuming that recalculating f-l-m properties can be done as
> a cheap side effect of applying faces.

Yes.

> I'm not at all sure this is the case.

This has been my experience in every single case.  And I think it's
no coincidence.


        Stefan