emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: address@hidden: Font Lock on-the-fly misfontification in C++]
Date: Mon, 31 Jul 2006 18:03:41 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

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

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

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


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]