GNU bug report logs -
#36397
CC Mode 5.34 (C++//l); Bad highlighting on inserting a string
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Tue, 23 Jul 2019 at 09:11, Alan Mackenzie <acm <at> 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!
[Message part 2 (text/html, inline)]
This bug report was last modified 6 years and 35 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.