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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36397 in the body.
You can then email your comments to 36397 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Richard Copley <rcopley <at> gmail.com>
To: submit <at> debbugs.gnu.org
Subject: CC Mode 5.34 (C++//l); Bad highlighting on inserting a string
Date: Wed, 26 Jun 2019 22:36:09 +0100

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

Package: cc-mode

Hi Alan,
Thanks for all your recent work on CC mode.
It isn't much fun to use, currently, on master. For example, from "emacs
-Q":

Add this text to a buffer in C or C++ mode (<<END):
int main ()
{
}
END

Add a double quote, inside main() or before it. (The double quote is
highlighted as an error. IIUC this is as expected now.)
Add another double quote. (Actual: both quotes and what comes after are
highlighted as a string. Expected: just the quotes are highlighted as a
string.)
Add a semicolon. (Actual: the semicolon is not highlighted but everything
after it is still highlighted as a string. Expected: just the quotes.)

Emacs  : GNU Emacs 27.0.50 (build 2, x86_64-w64-mingw32)
 of 2019-06-26
Package: CC Mode 5.34 (C++//l)
Buffer Style: gnu
c-emacs-features: (pps-extended-state col-0-paren posix-char-classes
gen-string-delim gen-comment-delim syntax-properties 1-bit)

current state:
==============
(setq
 c-basic-offset 2
 c-comment-only-line-offset '(0 . 0)
 c-indent-comment-alist '((anchored-comment column . 0) (end-block space .
1)
 (cpp-end-block space . 2))
 c-indent-comments-syntactically-p nil
 c-block-comment-prefix ""
 c-comment-prefix-regexp '((pike-mode . "//+!?\\|\\**") (awk-mode . "#+")
  (other . "//+\\|\\**"))
 c-doc-comment-style '((java-mode . javadoc) (pike-mode . autodoc)
      (c-mode . gtkdoc))
 c-cleanup-list '(scope-operator)
 c-hanging-braces-alist '((substatement-open before after)
 (arglist-cont-nonempty))
 c-hanging-colons-alist nil
 c-hanging-semi&comma-criteria '(c-semi&comma-inside-parenlist)
 c-backslash-column 48
 c-backslash-max-column 72
 c-special-indent-hook '(c-gnu-impose-minimum)
 c-label-minimum-indentation 1
 c-offsets-alist '((inexpr-class . +)
  (inexpr-statement . +)
  (lambda-intro-cont . +)
  (inlambda . 0)
  (template-args-cont c-lineup-template-args +)
  (incomposition . +)
  (inmodule . +)
  (innamespace . +)
  (inextern-lang . +)
  (composition-close . 0)
  (module-close . 0)
  (namespace-close . 0)
  (extern-lang-close . 0)
  (composition-open . 0)
  (module-open . 0)
  (namespace-open . 0)
  (extern-lang-open . 0)
  (objc-method-call-cont
   c-lineup-ObjC-method-call-colons
   c-lineup-ObjC-method-call
   +
   )
  (objc-method-args-cont . c-lineup-ObjC-method-args)
  (objc-method-intro . [0])
  (friend . 0)
  (cpp-define-intro c-lineup-cpp-define +)
  (cpp-macro-cont . +)
  (cpp-macro . [0])
  (inclass . +)
  (stream-op . c-lineup-streamop)
  (arglist-cont-nonempty
   c-lineup-gcc-asm-reg
   c-lineup-arglist
   )
  (arglist-cont c-lineup-gcc-asm-reg 0)
  (comment-intro
   c-lineup-knr-region-comment
   c-lineup-comment
   )
  (catch-clause . 0)
  (else-clause . 0)
  (do-while-closure . 0)
  (access-label . -)
  (case-label . 0)
  (substatement . +)
  (statement-case-intro . +)
  (statement . 0)
  (brace-entry-open . 0)
  (brace-list-entry . 0)
  (brace-list-close . 0)
  (block-close . 0)
  (block-open . 0)
  (inher-cont . c-lineup-multi-inher)
  (inher-intro . +)
  (member-init-cont . c-lineup-multi-inher)
  (member-init-intro . +)
  (annotation-var-cont . +)
  (annotation-top-cont . 0)
  (topmost-intro . 0)
  (knr-argdecl . 0)
  (func-decl-cont . +)
  (inline-close . 0)
  (class-close . 0)
  (class-open . 0)
  (defun-block-intro . +)
  (defun-close . 0)
  (defun-open . 0)
  (c . c-lineup-C-comments)
  (string . c-lineup-dont-change)
  (topmost-intro-cont
   first
   c-lineup-topmost-intro-cont
   c-lineup-gnu-DEFUN-intro-cont
   )
  (brace-list-intro
   first
   c-lineup-2nd-brace-entry-in-arglist
   c-lineup-class-decl-init-+
   +
   )
  (brace-list-open . +)
  (inline-open . 0)
  (arglist-close . c-lineup-arglist)
  (arglist-intro . c-lineup-arglist-intro-after-paren)
  (statement-cont . +)
  (statement-case-open . +)
  (label . 0)
  (substatement-label . 0)
  (substatement-open . +)
  (knr-argdecl-intro . 5)
  (statement-block-intro . +)
  )
 c-buffer-is-cc-mode 'c++-mode
 c-tab-always-indent t
 c-syntactic-indentation t
 c-syntactic-indentation-in-macros t
 c-ignore-auto-fill '(string cpp code)
 c-auto-align-backslashes t
 c-backspace-function 'backward-delete-char-untabify
 c-delete-function 'delete-char
 c-electric-pound-behavior nil
 c-default-style '((java-mode . "java") (awk-mode . "awk") (other . "gnu"))
 c-enable-xemacs-performance-kludge-p nil
 c-old-style-variable-behavior nil
 defun-prompt-regexp nil
 tab-width 8
 comment-column 32
 parse-sexp-ignore-comments t
 parse-sexp-lookup-properties t
 auto-fill-function nil
 comment-multi-line t
 comment-start-skip "\\(//+\\|/\\*+\\)\\s *"
 fill-prefix nil
 fill-column 70
 paragraph-start "[ ]*\\(//+\\|\\**\\)[ ]*$\\|^\f"
 adaptive-fill-mode t
 adaptive-fill-regexp "[ ]*\\(//+\\|\\**\\)[ ]*\\([ ]*\\([-–!|#%;>*·•‣⁃◦]+[
]*\\)*\\)"
 )

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

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

From: Alan Mackenzie <acm <at> muc.de>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 36397 <at> debbugs.gnu.org
Subject: Re: bug#36397: CC Mode 5.34 (C++//l); Bad highlighting on inserting
 a string
Date: Thu, 27 Jun 2019 11:11:54 +0000

Hello, Richard.

On Wed, Jun 26, 2019 at 22:36:09 +0100, Richard Copley wrote:

> Hi Alan,
> Thanks for all your recent work on CC mode.
> It isn't much fun to use, currently, on master. For example, from "emacs
> -Q":

> Add this text to a buffer in C or C++ mode (<<END):
> int main ()
> {
> }
> END

> Add a double quote, inside main() or before it. (The double quote is
> highlighted as an error. IIUC this is as expected now.)
> Add another double quote. (Actual: both quotes and what comes after are
> highlighted as a string. Expected: just the quotes are highlighted as a
> string.)
> Add a semicolon. (Actual: the semicolon is not highlighted but everything
> after it is still highlighted as a string. Expected: just the quotes.)

Yes, there is a bug here.  Sorry about that!  Thanks for taking the
trouble to report it.

The bug is to do with incorrect coding for handling a newline becoming
an escaped newline.

There are more than just that one coding error in this area, and I'd
like to fix them all at the same time.  In the meantime, please try out
this patch, and let me know how well it works.  Thanks!


diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
index 5c18879712..ff358aae72 100644
--- a/lisp/progmodes/cc-mode.el
+++ b/lisp/progmodes/cc-mode.el
@@ -1262,11 +1262,12 @@ c-before-change-check-unbalanced-strings
 	  (setq c-new-BEG (min (car beg-limits) c-new-BEG))))
 
      ((< end (point-max))
-      (goto-char (1+ end))	; might be a newline.
-      ;; In the following regexp, the initial \n caters for a newline getting
-      ;; joined to a preceding \ by the removal of what comes between.
-      (re-search-forward "[\n\r]?\\(\\\\\\(.\\|\n\\)\\|[^\\\n\r]\\)*"
-			 nil t)
+      ;; Move to end of logical line (as it will be after the change)
+      (goto-char (if (and (memq (char-after end) '(?\n ?\r))
+			  (eq (char-before beg) ?\\))
+		     (1+ end)
+		   end))
+      (re-search-forward "\\(\\\\\\(.\\|\n\\)\\|[^\\\n\r]\\)*" nil t)
       ;; We're at an EOLL or point-max.
       (if (equal (c-get-char-property (point) 'syntax-table) '(15))
 	  (if (memq (char-after) '(?\n ?\r))



> Emacs  : GNU Emacs 27.0.50 (build 2, x86_64-w64-mingw32)
>  of 2019-06-26
> Package: CC Mode 5.34 (C++//l)
> Buffer Style: gnu
> c-emacs-features: (pps-extended-state col-0-paren posix-char-classes
> gen-string-delim gen-comment-delim syntax-properties 1-bit)

[ CC Mode configuration appreciated, but snipped. ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #11 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: Fri, 28 Jun 2019 14:28:29 +0100

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

On Thu, 27 Jun 2019 at 12:11, Alan Mackenzie <acm <at> muc.de> wrote:

> There are more than just that one coding error in this area, and I'd
> like to fix them all at the same time.  In the meantime, please try out
> this patch, and let me know how well it works.  Thanks!
>

That seems to work just fine, thank you. I'll keep it in my local clone of
the master branch for the time being.
Thank you.

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

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

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

Hello, Richard.

On Fri, Jun 28, 2019 at 14:28:29 +0100, Richard Copley wrote:
> On Thu, 27 Jun 2019 at 12:11, Alan Mackenzie <acm <at> muc.de> wrote:

> > There are more than just that one coding error in this area, and I'd
> > like to fix them all at the same time.  In the meantime, please try out
> > this patch, and let me know how well it works.  Thanks!

> That seems to work just fine, thank you. I'll keep it in my local clone
> of the master branch for the time being.  Thank you.

OK.  I think this bug is now fixed in the current master, in particular
after the commit 585fb957399f21a93cbfabd182b76262466797e3 from yesterday,
"CC Mode: allow bogusly "adjacent" double quote marks to pair up
syntactically".

I've had several bugs with overlapping causes to fix, so apologies that
bug #36397 kind of got pushed down the stack.

Could I ask you, please, to check whether the bug is indeed fixed in
master, and let me know.  If it is, I can then close the bug.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #17 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: Thu, 18 Jul 2019 10:19:42 +0100

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

On Wed, 17 Jul 2019 at 11:49, Alan Mackenzie <acm <at> muc.de> wrote:

    Hello, Richard.

    On Fri, Jun 28, 2019 at 14:28:29 +0100, Richard Copley wrote:
    > On Thu, 27 Jun 2019 at 12:11, Alan Mackenzie <acm <at> muc.de> wrote:

    > > There are more than just that one coding error in this area, and I'd
    > > like to fix them all at the same time.  In the meantime, please try
out
    > > this patch, and let me know how well it works.  Thanks!

    > That seems to work just fine, thank you. I'll keep it in my local
clone
    > of the master branch for the time being.  Thank you.

    OK.  I think this bug is now fixed in the current master, in particular
    after the commit 585fb957399f21a93cbfabd182b76262466797e3 from
yesterday,
    "CC Mode: allow bogusly "adjacent" double quote marks to pair up
    syntactically".

    I've had several bugs with overlapping causes to fix, so apologies that
    bug #36397 kind of got pushed down the stack.

    Could I ask you, please, to check whether the bug is indeed fixed in
    master, and let me know.  If it is, I can then close the bug.

Thanks Alan,
There are still some issues with fontifying strings. I reverted the patch
you provided earlier and rebuilt from master.

From Emacs -Q, visit an empty or absent file in C++ mode and type the
following (two slashes, a space and a double quote):

// "

Actual: The double quote is highlighted in font-lock-warning-face.
Expected: font-lock-comment-face.

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

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

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

Hello, Richard.

On Thu, Jul 18, 2019 at 10:19:42 +0100, Richard Copley wrote:
> On Wed, 17 Jul 2019 at 11:49, Alan Mackenzie <acm <at> muc.de> wrote:

>     On Fri, Jun 28, 2019 at 14:28:29 +0100, Richard Copley wrote:
>     > On Thu, 27 Jun 2019 at 12:11, Alan Mackenzie <acm <at> muc.de> wrote:

>     > > There are more than just that one coding error in this area,
>     > > and I'd like to fix them all at the same time.  In the
>     > > meantime, please try out this patch, and let me know how well
>     > > it works.  Thanks!

>     > That seems to work just fine, thank you. I'll keep it in my
>     > local clone of the master branch for the time being.  Thank you.

>     OK.  I think this bug is now fixed in the current master, in
>     particular after the commit
>     585fb957399f21a93cbfabd182b76262466797e3 from yesterday, "CC Mode:
>     allow bogusly "adjacent" double quote marks to pair up
>     syntactically".

>     I've had several bugs with overlapping causes to fix, so apologies that
>     bug #36397 kind of got pushed down the stack.

>     Could I ask you, please, to check whether the bug is indeed fixed in
>     master, and let me know.  If it is, I can then close the bug.

> Thanks Alan,
> There are still some issues with fontifying strings. I reverted the patch
> you provided earlier and rebuilt from master.

> >>From Emacs -Q, visit an empty or absent file in C++ mode and type the
> following (two slashes, a space and a double quote):

> // "

> Actual: The double quote is highlighted in font-lock-warning-face.
> Expected: font-lock-comment-face.

Thanks for spotting that.  There were a couple of bugs left concerning
unterminated comments (i.e. ones which just "ended" at EOB, rather than
having a */ or NL to terminate them).

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!


diff -r 7bee52fd72a1 cc-engine.el
--- a/cc-engine.el	Wed Jul 17 09:23:34 2019 +0000
+++ b/cc-engine.el	Fri Jul 19 10:18:11 2019 +0000
@@ -2868,6 +2868,7 @@
 ;; element is a list (HERE STATE END)), where HERE is the buffer position the
 ;; function was called for, STATE is the `parse-partial-sexp' state there, and
 ;; END is the end of the literal enclosing HERE, if any, or nil otherwise.
+;; N.B. END will be nil if the literal ends at EOB without a delimiter.
 
 (defun c-full-trim-near-cache ()
   ;; Remove stale entries in `c-full-lit-near-cache', i.e. those whose END
@@ -2936,7 +2937,8 @@
   ;; (STATE)                    otherwise,
   ;; where STATE is the parsing state at HERE, TYPE is the type of the literal
   ;; enclosing HERE, (one of 'string, 'c, 'c++) and (BEG . END) is the
-  ;; boundaries of that literal (including the delimiters).
+  ;; boundaries of that literal (including the delimiters), with END being nil
+  ;; if there is no end delimiter (i.e. the literal ends at EOB).
   ;;
   ;; Unless NOT-IN-DELIMITER is non-nil, when TO is inside a two-character
   ;; comment opener, this is recognized as being in a comment literal.
@@ -2955,6 +2957,7 @@
 	       (base (car elt))
 	       (near-base base)
 	       (s (cadr elt))
+	       s1
 	       (end (car (cddr elt)))
 	       far-base-and-state far-base far-s ty start)
 	  (if (or
@@ -2995,12 +2998,17 @@
 		      (t 'c)))
 	    (setq start (nth 8 s))
 	    (unless end
-	      (parse-partial-sexp here (point-max)
-				  nil	     ; TARGETDEPTH
-				  nil	     ; STOPBEFORE
-				  s	     ; OLDSTATE
-				  'syntax-table) ; stop at end of literal
-	      (setq end (point)))
+	      (setq s1 (parse-partial-sexp here (point-max)
+					   nil		  ; TARGETDEPTH
+					   nil		  ; STOPBEFORE
+					   s		  ; OLDSTATE
+					   'syntax-table)); stop at EO literal
+	      (unless (or (nth 3 s1)			  ; still in a string
+			  (and (nth 4 s1)
+			       (not (eq (nth 7 s1) 'syntax-table)))) ; still
+								     ; in a
+								     ; comment
+		(setq end (point))))
 	    (unless (eq near-base here)
 	      (c-full-put-near-cache-entry here s end))
 	    (list s ty (cons start end)))
@@ -5454,8 +5462,11 @@
 						   s
 						   'syntax-table)
 			       (point)))))
-	    (let ((pp-to-lit (c-full-pp-to-literal pos not-in-delimiter)))
-	      (car (cddr pp-to-lit))))))
+	    (let* ((pp-to-lit (c-full-pp-to-literal pos not-in-delimiter))
+		   (limits (car (cddr pp-to-lit))))
+	      (if (and limits (null (cdr limits)))
+		  (cons (car limits) (point-max))
+		limits)))))
       (cond
        (lit-limits)
 
diff -r 7bee52fd72a1 cc-mode.el
--- a/cc-mode.el	Wed Jul 17 09:23:34 2019 +0000
+++ b/cc-mode.el	Fri Jul 19 10:18:11 2019 +0000
@@ -1509,7 +1509,9 @@
 			   (or (not (nth 3 s))
 			       (not (memq (char-before) c-string-delims))))))
 	     ;; We're at the start of a string.
-	     (memq (char-before) c-string-delims)))
+	     (and (memq (char-before) c-string-delims)
+		  (not (nth 4 s)))))	; Check we're actually out of the
+					; comment. not stuck at EOB
 	(unless (and (c-major-mode-is 'c++-mode)
 		     (c-maybe-re-mark-raw-string))
 	  (if (c-unescaped-nls-in-string-p (1- (point)))


-- 
Alan Mackenzie (Nuremberg, Germany).

Message #23 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: Sat, 20 Jul 2019 09:43:04 +0100

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

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.

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

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)]

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

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

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!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 36397-done <at> debbugs.gnu.org
Subject: Re: bug#36397: CC Mode 5.34 (C++//l); Bad highlighting on inserting
 a string
Date: Tue, 23 Jul 2019 10:02:56 +0000

Hello, Richard.

On Mon, Jul 22, 2019 at 20:47:22 +0100, Richard Copley wrote:
> 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!

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

[ .... ]

Indeed, not.  Now that the things in the original bug have been fixed,
I'm closing this bug.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 36397 <at> debbugs.gnu.org
Subject: Wierd fontification in brackets in C++ Mode.  [Was bug#36397: CC
 Mode 5.34 (C++//l); Bad highlighting on inserting a string]
Date: Tue, 23 Jul 2019 10:40:15 +0000

Hello again, Richard.

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

[ .... ]

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

OK, I've tracked this one down to a regexp not testing for end of word.

I'm pretty sure the following patch fixes it, but would you please do the
usual with it anyway.  As this changes a Lisp macro, the entire CC Mode
needs to be rebuilt after patching.

Thanks!


diff -r 2e20f0567ddf cc-langs.el
--- a/cc-langs.el	Tue Jul 23 09:45:20 2019 +0000
+++ b/cc-langs.el	Tue Jul 23 10:34:14 2019 +0000
@@ -1480,7 +1480,7 @@
 
 (c-lang-defconst c-pre-lambda-tokens-re
   ;; Regexp matching any token in the list `c-pre-lambda-tokens'.
-  t (regexp-opt (c-lang-const c-pre-lambda-tokens)))
+  t (c-make-keywords-re t (c-lang-const c-pre-lambda-tokens)))
 (c-lang-defvar c-pre-lambda-tokens-re (c-lang-const c-pre-lambda-tokens-re))
 
 ;;; Syntactic whitespace.



-- 
Alan Mackenzie (Nuremberg, Germany).

Message #40 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: Wed, 24 Jul 2019 20:25:40 +0100

[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)]

Message #43 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: Wed, 24 Jul 2019 21:09:07 +0100

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

On Wed, 24 Jul 2019 at 20:25, Richard Copley <rcopley <at> gmail.com> wrote:

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

        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.

bug#36801, "Weird fontification in brackets in C++ Mode" [1].
bug#36802, "Spurious indentation in line after open #include" [2].

[1] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36801>
[2] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36802>

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