unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* Re: [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]
       [not found] <E1CsBPC-0004xn-8P@fencepost.gnu.org>
@ 2005-02-19  0:03 ` Martin Stjernholm
  0 siblings, 0 replies; only message in thread
From: Martin Stjernholm @ 2005-02-19  0:03 UTC (permalink / raw)
  Cc: bug-cc-mode, bug-gnu-emacs, rms

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.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2005-02-19  0:03 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <E1CsBPC-0004xn-8P@fencepost.gnu.org>
2005-02-19  0:03 ` [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows] Martin Stjernholm

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).