On Sat, 20 Jul 2019 at 09:43, Richard Copley <rcopley@gmail.com> wrote:
On Fri, 19 Jul 2019 at 11:43, Alan Mackenzie <acm@muc.de> wrote:
I think the following patch fixes them.  Would you try it out, please,
and confirm to me that this does fix that bug, or tell me about any
further faults you see.  Then, hopefully, we can finally close this bug.

Thanks!

Thank you! I plan to get some things done in C++ this weekend.
I haven't noticed any problems so far. If I do I'll let you know.

Here are some things. Whether any of them is related to the issue we were discussing, I can't say. Probably not. I didn't notice anything obviously similar to the issue we were discussing, about string delimiters. Most serious first:

1. (This one's reproducible from emacs -Q). In an empty C++ buffer, type [#include SPC <ab> C-p BACKSPACE C-e RET]. The new line is indented one level (expected zero levels). This corrects itself after doing M-x normal mode.

2. I noticed odd words being highlighted, but I don't know how to recreate such situations reliably. For example, today after a little hacking I ended up with a statement like this:

  auto [writer, eagle, headquarters, stun, pat] = get_things();

A random-seeming subset of the words in the identifier-list were highlighted as types, but this corrected itself after doing M-x normal mode.

3. (This one's reproducible and 'stable' -- it's dependent only on the current buffer contents, and not on the path that got us there.) With these buffer contents:

order[x];
origin[y];
counterpane[z];

... "x" and "y" are highlighted as types, and "z" is not (expected: none of the three subscripts are highlighted). There's apparently something special about the identifiers "order" and "origin".