bug#11386: C++11 support: C++ mode gets (temporarily) confused by edits to convert "> >" to ">>" in templates

bug#11386: C++11 support: C++ mode gets (temporarily) confused by edits to convert "> >" to ">>" in templates

[James Dennett]

C++ mode gets confused if C++98 code is updated to omit the (now
unnecessary) space between the closing ">" angle brackets in template
argument lists.

To reproduce:

Start by typing the following (C++98) code:

int foo() {
  vector<vector<string> > temp;
}

So far, so good. Now go back and remove the extra space between the
closing angle brackets.  This will cause the closing } to not match
the opening { (according to emacs), so if you then add another
function below foo, you'll get something like:

int foo() {
  vector<vector<string>> temp;
  return 0;
}

      int bar() {
  }

where the indentation of everything after the function foo() is
broken.  Matching of the angle brackets is also broken.

The buffer can be restored to a good state by erasing and retyping the
inner "<" in the type.  Adding the extra space and removing it will
put the buffer back in a bad state.  Reading the code from file (with
or without the extra space) also leaves the buffer in a good state.

bug#11386: C++11 support: C++ mode gets (temporarily) confused by edits to convert "> >" to ">>" in templates

[Rüdiger Sonderfeld]

tags 11386 fixed

Should be fixed in 66bb9533fc77963c495de7f33ec6dc8e4d342a55

bug#11386: C++11 support: C++ mode gets (temporarily) confused by edits to convert "> >" to ">>" in templates

[Alan Mackenzie]

Guten Abend, Ruediger.

In article <mailman.13959.1416330148.1147.bug-gnu-emacs@gnu.org> you wrote:
> tags 11386 fixed

> Should be fixed in 66bb9533fc77963c495de7f33ec6dc8e4d342a55

OUTCH!!!

Any chance you could be a little more informative with messages like this,
please?

The message as it stands suggests "I have just committed a fix as revision
66bb95...".  The id 66bb95..., like all ids in git, carries no context,
no age, no nothing.

Better would have been to use the "present perfect" tense: "Should have
been fixed in 66bb95...", which would have placed the action of fixing
in the non-immediate past.

Better still would have been to give details of the fix, something like
"Should have been fixed in 66bb953... by Alan Mackenzie in August, title
line "Make ">>" act as double template ender in C++ Mode."".

Possibly the best thing of all would have been to construct an Eric
Raymond style commit identifier, but I haven't got the syntax memorised
yet.

Any of these would have prevented me errupting in uncalled-for panic and
fury.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).