[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: Font Lock on-the-fly misfontification in C++]
From: |
Alan Mackenzie |
Subject: |
Re: address@hidden: Font Lock on-the-fly misfontification in C++] |
Date: |
Tue, 1 Aug 2006 10:21:47 +0100 |
User-agent: |
Mutt/1.5.9i |
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.
Re: address@hidden: Font Lock on-the-fly misfontification in C++], Aidan Kehoe, 2006/08/02