Re: [address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]

[Martin Stjernholm]

Richard Stallman <rms@gnu.org> wrote:

> Would you please fix this, if it is still broken in the current
> sources?
>
> From: Erik <sigra@home.se>
> Subject: C++-mode: Syntax highlighting: wrong color for function identifier
>       depending on the kind of whitespace that follows
> To: bug-gnu-emacs@gnu.org
> Date: Fri Jan 21 18:44:19 2005 +0100
>
> In GNU Emacs 21.3.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)

If I'm not mistaken, that version contains CC Mode 5.28, which is
before CC Mode took over the font locking responsibility. Still, the
situation is the same in 5.30, so I'll address the problem anyway, but
my discussion will be in the context of 5.30 and not 5.28.

> In C++-mode, type:
> void function(int x);
>
> The string "function" is blue, which is correct. Now type:
> void function           (int x);
>
> The color is still correct. But type:
> void function
>                         (int x);
>
> The color is suddenly yellow. This is clearly a bug.

I assume yellow is the color you have for font-lock-variable-name-face.

As I understand this, you type in your examples sequentially. I.e. at
one time the buffer contains the single line

    void function

and then you add a newline and continue to type "(int x)". If so, the
bug, or rather misfeature, is in the font-lock package: By design, it
only refontifies the current line on the fly. When you're leaving the
first line, CC Mode is only acting on the information given by the
incomplete declaration "void function", which it prefers to recognize
as a variable declaration. It's first when you enter the "(" on the
second line that it can correct that analysis. But then font-lock no
longer requests refontification of the line containing the function
name.

Both the font-lock package and CC Mode could be improved in this
regard, but in general it's very tricky to know whether a change
affects the meaning of some code further back in the buffer. To be
really correct, the whole buffer down to the point should be
considered for refontification for every change in the buffer.
Needless to say that would get much too slow very quickly.

In the cvs version of Emacs, the font-lock package has a new variable
`font-lock-multiline'. It doesn't appear to make a difference in this
case.

> /.../ The color of function identifiers should always be the same,
> and not depend on what kind of whitespace follows it.

Indeed, and the font lock patterns installed by CC Mode do consider
all syntactic whitespace the same, regardless of amount of newlines,
comments and preprocessor directives in it. But it's necessary to
fontify the whole region at once to get that into play.