bug#4847: C++ Mode mistreats < and > as balanced delimiters

bug#4847: C++ Mode mistreats < and > as balanced delimiters

[Taylor R Campbell]

GNU Emacs 22.3.1 (i386-apple-darwin9.7.0, GTK+ Version 2.12.9) of 2009-08-10 on Oberon.local

In an empty buffer in C++ Mode, type

if (foo < bar) { }

and then change it to

if (foo < > bar) { }

and then change it back.

Now your buffer is in a bogus state, with Emacs thinking that the < is
mismatched with the ), and that there is nothing matching the (.

It is OK not to treat angle brackets as delimiters when they are, in
templates: it requires a little extra work by the user (to see, edit,
indent, &c., the balanced pairs), but doesn't break anything.

It is not OK to treat angle brackets as delimiters when they aren't,
in comparisons and shifts: it breaks the entire structure of the text
in the buffer, and thus it breaks swaths of commands that users use
all the time without thinking such as C-M-f and C-M-b.

If Emacs has the option of being clever about angle brackets in
templates, the user should have the option of disabling it because it
is incredibly frustrating when the cleverness fails.  But I couldn't
find any way to disable this broken cleverness, by aproposing for
`C++', by reading the CC Mode manual, or by skimming the (unbelievably
hairy) code.

I even tried to fool C++ Mode by changing the entries for ?< and ?> in
c++-mode-syntax-table, which didn't help because that's not where the
guilty entries are; by changing c++-template-syntax-table, which
didn't help because it is not globally defined and apparently
regenerated for each instance of C++ Mode; and by adding a hook to
c++-mode-hook which changes c++-template-syntax-table, which still
didn't work, at which point I lost interest in trying to figure out
this mess.  So it seems as though C++ Mode takes special effort to
thwart any attempts to work around its broken cleverness surrounding
angle brackets.

bug#4847: C++ Mode mistreats < and > as balanced delimiters

[Glenn Morris]

Version: 24.1

I see this problem in Emacs 23.3, but not in the current trunk, so it
looks like it has been fixed.