GNU bug report logs - #36397
CC Mode 5.34 (C++//l); Bad highlighting on inserting a string

Previous Next

Full log

Message #26 received at 36397 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 36397 <at> debbugs.gnu.org
Subject: Re: bug#36397: CC Mode 5.34 (C++//l);
 Bad highlighting on inserting a string
Date: Mon, 22 Jul 2019 20:47:22 +0100

[Message part 1 (text/plain, inline)]

On Sat, 20 Jul 2019 at 09:43, Richard Copley <rcopley <at> gmail.com> wrote:

> On Fri, 19 Jul 2019 at 11:43, Alan Mackenzie <acm <at> 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".

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.