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

[Stefan Monnier]

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

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.

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

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

> I think I'd need to put a `c-beginning-of-statement-1' thing in the bit
> of code which would apply f-l-multiline.  I think I'd need to call that
> function lots of times, in each fontification routine.

You'll probably need that indeed for /identification/.


        Stefan