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

[Alan Mackenzie]

Morning, Stefan!

On Mon, Jul 31, 2006 at 06:03:41PM -0400, Stefan Monnier wrote:
> >> The patch below seems to fix number 2 and 3 for me.  Someone who
> >> understands cc-fonts.el better than me and thus knows where the two
> >> "public XXX" lines are handled could probably do a similar
> >> adjustment for them.

> > At the very least, this isn't suitable for the CC Mode repository,
> > since font-lock-multiline hasn't (yet?) been implemented in XEmacs
> > or older GNU Emacsen.

> I find it quite suitable, personally, since although it indeed only
> fixes the OP's problem under Emacs-22 (and Emacs-21 if you're willing
> to set the font-lock-multiline variable to t), it won't hurt in
> Emacs-20 or XEmacs.

> Better yet: you can make it work under any old font-lock
> implementation (Emacs-19/20/21, XEmacs-??) by using
> font-lock-fontify-region-function to obey the font-lock-multiline
> property.

And yes, f-l-fontify-region-function does exist in XEmacs.  :-)

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?

> > I don't know cc-fonts.el that well myself, yet, but I get the
> > feeling that putting in f-l-multiline properties like this is, at
> > best, only going to converge gradually on a working solution [to the
> > problem of CC Mode lines being fontified out of context].  How will
> > we know when every case has been covered?

> - Check every place where you set faces
> - see on which part of the buffer's text this highlighting decision
>   depends
> - add a f-l-multiline property on it if it spans more than a line (or
>   even: add a f-l-multiline property on it no matter what if you
>   prefer it that way).

> If you've indeed checked every place where a highlighting is added,
> then you know you've covered all cases.

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 ;

> > As I've said once or twice before, I'd prefer to calculate the f-l
> > change region explicitly at each change.

> I have a hard time imagining how that's going to be very different:
> you'll have to check every possible situation to figure out which
> region to use.

:-)  You're probably right there, too!

Actually, the convergence would be from a different direction: I'd start
using (I think) c-beginning-of-statement-1, which would be reliable but
unbearably sluggish, then optimise the sluggishness away with caching
mechanisms and whatnot.

> How will you know that you indeed haven't missed one possible case?
> Since the cases you care about are those handled by your highlighting
> code, I'd expect it's easier to make sure you've covered all cases if
> you add the code directly where you handle each case.

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:

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

I think that's because we have very different conceptual models of code.
I think that having f-l-multiline code throughout the existing
cc-fonts.el would be more difficult to test (and much easier to forget
about when making other changes) than having a distinct function
c-beginning-of-font-lock-region.


>         Stefan

-- 
Alan.