Hello, Richard.

On Mon, Jul 22, 2019 at 20:47:22 +0100, Richard Copley wrote:

> Here are some things. Whether any of them is related to the issue we were
> discussing, I can't say. Probably not.

I don't think they're related, either.  I think it is time to close the
bug, and maybe open some new ones.  ;-)

> 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.

Yes, I can reproduce this, though I've no idea what's causing it at the
moment.

> 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.

I strongly suspect this is CC Mode's "found type" mechanism - whenever an
identifier occurs in a context which must be a type, it is recorded as
such in a special obarray (or is it a hash table?).  Other occurrences of
the same identifier then get fontified as types.

You can check this with M-: (c-list-found-types).  Moreover, you can
clear the list of found types by going to the beginning of the buffer and
making an arbitrary change.  (Then undo it).

> 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".

I've half tracked this down.  There is a regular expression which matches
certain operators and keywords (the ones which can be overloaded), but in
the latter case, it fails to check for end of word.  So x and y get
fontified because order and origin both start with "or".  The same thing
happens with android and bitorder, which begin with "and" and "bitor".

I should be able to determine the exact mechanism fairly mechanically.

So, in summary, I will be closing the original bug today (or soon).  I
will be looking into the first and third new matters you've raised, and
would welcome bug reports being raised for them.

As for the second
matter (about fontification of random words), would you please check
whether this actually is being caused by the "found types" mechanism, as
I have outlined above.

Thanks, and have a good day!