Subject: bug#5422: syntax highlighting bug

From: Alan Mackenzie <[email-masked]>
Date: Thu, 6 Oct 2011 15:38:14 +0000

On Tue, Oct 04, 2011 at 07:32:57AM +0200, Jan Djärv wrote:
> Hello.

> 3 okt 2011 kl. 22:59 skrev Glenn Morris <[email-masked]>:

> > Bartosz Lew wrote:

> >> This is just to report on some minor C++ syntax highlighting problem
> >> in emacs.

> >> when I write:

> >>    if (a < b->c())  { do this; } else { do that; }

> >> two two things go wrong:
> >> 1) parentheses matching doesn't work correctly 
> >>    emacs matches the closing bracket of the if condition with the
> >> "<" - "smaller > than" sign in the if condition.

> >> 2) the automatic positioning of any code written below gets confused due to 
> >> this parentheses matching problem.

> >> I use:

> >> GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.16.6)
> >> of 2009-09-29 on x86-7.fedora.phx.redhat.com

> > I am unable to reproduce this in any version of Emacs, including 23.1.
> > If you still see the problem in the latest release, please send a
> > complete example starting from emacs -Q.

> > (There seem to have been some fixes in this area, eg
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4847 )

> This is one of the elusive cc-mode bugs that isn't easy to reproduce. 

> AFAIK it depends on some cache in cc-mode getting out of sync. So you
> are more likely to see it on a large file you have edited in several
> places. It might even depend on what kind of editing you have done. I
> think this is a symptom of some underlying bug.

> I see this in 23.3 and the trunk at least 2-3 times per day when
> editing code with a lot of templates. The < and > are mistaken for
> start/end brace or parentesis.

The < and > are marked (with syntax-table text properties) as parens when
they "look like" template brackets, as they sort of do in the OP's code.
Many moons ago, < and > got marked as parens individually.  Now they are
only marked in pairs.

This has quite likely fixed the OP's bug.

> Save the file, kill the buffer, and reopen the file usually fixes it.

Yes.  But that "shouldn't" be necessary any more.

>     Jan D.

-- 
Alan Mackenzie (Nuremberg, Germany).