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

[Alan Mackenzie]

'Evening, Stefan!

On Tue, Aug 01, 2006 at 10:55:41AM -0400, Stefan Monnier wrote:
> > As a matter of interest, does the f-l-multiline mechanism somehow
> > work with a _first_ fontification?  Assume CC Mode has been enhanced
> > to use f-l-multiline.  Say we have a buffer of C source in
> > fundamental mode (so there're no f-l-m properties on the buffer), and
> > the top of the screen is in the middle of a C construct.  If we do
> > M-x c-mode, will the top line get correctly fontified?

> No, as explained in the lispref manual, to handle multiline elements,
> you have to handle both /rehighlighting/ (e.g. Simon's problem that
> started this thread) and /identification/ (e.g. what you describe here)
> and although the two are closely related, they cannot be handled in the
> same way.

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?  It's going to be more code.  Might it, for
example, be faster? 

> The f-l-multiline property allows you to handle /rehighlighting/ but
> not /identification/.

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

> > I don't agree here; a bug report from Peter Dyballa (back in February or
> > March) gave this as an example:

> >> /* lots of things don't have <malloc.h> */
> >> /* A/UX systems include it from stdlib, from Xos.h */
> >> #ifndef VMS   /* VMS hates multi-line '#if's */
> >> # if !defined(ibm032)                    && \
> >> !defined(__convex__)                && \
> >> !(defined(vax) && !defined(ultrix)) && \
> >> !defined(mips)                      && \
> >> !defined(apollo)                    && \
> >> !defined(pyr)                       && \
> >> !defined(__UMAXV__)                 && \
> >> !defined(bsd43)                     && \
> >> !defined(__bsd43)                   && \
> >> !(defined(BSD) && (BSD >= 199103))  && \
> >> !defined(aux)                       && \
> >> !defined(__bsdi__)                  && \
> >> !defined(sequent)

> >> As the attached picture shows some "defined" keywords are not
> >> emphasised:

> I don't know whether the bug was that the `defined' keywords were not
> originally correctly fontified (problem of /identification/), or whether
> their correct highlighting was preserved when editing the text (problem of
> /rehighlighting/).  If it's the former, then it's unrelated to what I'm
> talking about.

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.

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.

> > There is nothing in the functions currently in cc-fonts capable of
> > locating the opening "# if" when one of the subsequent lines is
> > changed.

> If the original highlighting was correct, then when you did this
> original highlighting you happened to know where the "# if" was located
> (even though you don't have any code that can find it in the general
> case) and you could have remembered that info by placing a
> font-lock-multiline property.

In the above example, the file has merely been loaded with C-x C-f.  I
suspect that the fontification goes awry where the display code splits
the buffer into ~500 byte chunks.

>         Stefan

-- 
Alan.