On Tue, 23 Jul 2019 at 09:11, Alan Mackenzie <acm@muc.de> wrote:

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


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


I keep meaning to get around to this.


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

Yes, that's it.


> Thanks, and have a good day!
>

 I did, thank you. Have a good day!