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

[Stefan Monnier]

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

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

>> > 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 expect that the difference is not in the approaches but in their
particular implementation at a particular moment in time.

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

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


        Stefan