[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: Alan Mackenzie
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 19:23:22 +0000 (GMT)

Hi, Richard!

On Sun, 12 Feb 2006, Richard M. Stallman wrote:

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

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'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.  There are surely much better formatted buffers
which also need the region to start in the middle of a line.

I've also created a new @subsection in modes.texi, "Region to Fontify",
which documents font-lock-extend-region-function, and I've moved
font-lock-lines-before into it.


reply via email to

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