[Top][All Lists]

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

Re: address@hidden: C++-mode: Syntax highlighting: wrong color for funct

From: Stefan Monnier
Subject: Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]
Date: Tue, 14 Mar 2006 17:11:59 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>> Here's the change I was talking about.  Would someone please adapt
>> this _now_ to the current sources, and install it?  Then please rename
>> before-font-lock-after-change-function to
>> font-lock-extend-region-function, and rename
>> font-lock-run-before-after-change-hook to font-lock-extend-region?

>> Then please ack this message.

> DONE.  In the process, I moved the processing of font-lock-lines-before
> from font-lock-default-fontify-region into
> font-lock-after-change-function and jit-lock-after-change, so as to be
> able to stop them interfering with eachother.

As discussed and agreed in this list, font-lock-lines-before should simply
be removed since it is subsumed by the new feature.

Also, I thought we had agreed that this new feature should be in
f-l-default-fontify-region rather than f-l-after-change-function.  I believe
it is *wrong* for it to be in f-l-after-change-function where it is mostly
useless: you can already get the same result by using an
(non-f-l)after-change-functions hook that sets the
font-lock-multiline property.

> More controversially, I've explicitly documented that the region returned
> by the f-l-extend-region may start or end in the middle of a line.

I don't care much either way.  If someone does that, it's his problem: it
won't hurt font-lock.el.  But it may screw up the other font-lock-keywords.

> I'm not sure whether that will work properly at the moment (I suspect it
> won't), but I think it can be and should be fixed.  I'm thinking about
> a piece of badly formatted C code something like:

> 1. int foo (int
> 2.          bar) {printf "Hello world"} ; int baz
> 3.   (int omg) {

> The "baz" on L3 hasn't a snowball's chance in Hades of getting fontified
> with f-l-function-name-face unless the font lock region is allowed to
> start at the "int" on L2.

Why?  After all, when you open the file, the region will start at BOB.


reply via email to

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