GNU bug report logs - #58537
CC Mode 5.35.1 (C/*l); Keywords being fontified as types at random

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 58537 in the body.
You can then email your comments to 58537 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: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: CC Mode 5.35.1 (C/*l); Keywords being fontified as types at random
Date: Sat, 15 Oct 2022 11:42:26 +0800

Package: cc-mode

Sometimes, immediately before typing the closing parentheses of a
function invocation, like so:

void
dm_apply_screen_again (window, drawable, root_x, root_y)
     dm_root_window_ptr window;
     dm_root_window_drawable_ptr drawable;
{
  dm_lock_type type;
  dm_screen_ptr screen;
#if 1
  dm_tgs_reply_ptr client_data;
#else
  caddr_t client_data;
#endif
  dm_screen_lock_ptr lock;

  /* Private code elided.  */

  dm_apply_pointer_lock (window, lock

every occurrence of "lock", "root_x", and "root_y" in the file becomes
fontified as a type, and is stuck that way.  The only way to stop those
keywords from being fontified as types is by reenabling c-mode.

This did not happen in Emacs 28; I can't reproduce the bug with a file
that I can share, but I will keep trying to make one.

Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu)
 of 2022-10-15
Package: CC Mode 5.35.1 (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 category-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++-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 '(t 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 #8 received at 58537 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: 58537 <at> debbugs.gnu.org
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Sun, 16 Oct 2022 15:20:49 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> Package: cc-mode
>
> Sometimes, immediately before typing the closing parentheses of a
> function invocation, like so:
>
> void
> dm_apply_screen_again (window, drawable, root_x, root_y)
>      dm_root_window_ptr window;
>      dm_root_window_drawable_ptr drawable;
> {
>   dm_lock_type type;
>   dm_screen_ptr screen;
> #if 1
>   dm_tgs_reply_ptr client_data;
> #else
>   caddr_t client_data;
> #endif
>   dm_screen_lock_ptr lock;
>
>   /* Private code elided.  */
>
>   dm_apply_pointer_lock (window, lock
>
> every occurrence of "lock", "root_x", and "root_y" in the file becomes
> fontified as a type, and is stuck that way.  The only way to stop those
> keywords from being fontified as types is by reenabling c-mode.
>
> This did not happen in Emacs 28; I can't reproduce the bug with a file
> that I can share, but I will keep trying to make one.

I think I have a reproducible recipe for this now, which I got while
working on a completely different program.

First, insert the following text in a buffer:

RelativePointer *
XLSeatGetRelativePointer (Seat *seat, struct wl_resource *resource)
{
  RelativePointer *relative_pointer;
  SeatClientInfo *info;

  /* Create a relative pointer object for the relative pointer
     resource RESOURCE.  */

  relative_pointer = XLCalloc (1, sizeof *relative_pointer);
  info = CreateSeatClientInfo (wl_resource_get_client (resource));

  /* Link the relative pointer onto the seat client info.  */
  relative_pointer->next = info->relative_pointers.next;
  relative_pointer->last = &info->relative_pointers;

  /* Then, the seat.  */
  relative_pointer->seat = seat;
  RetainSeat (seat);
}

then, move to the end of the buffer.  Turn on electric-pair-mode and
c-mode.  Type:

v SPC o SPC i SPC d RET X L S e a t D e s t r o y R e l a t i v e P o i
n t e r SPC ( R e l a t i v e P o i n t e r SPC * r e l a t i v e _ p o
i n t e r C-e

every occurrence `relative_pointer' will be refontified as a type, and
become stuck that way.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 58537 <at> debbugs.gnu.org, acm <at> muc.de
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Sun, 16 Oct 2022 20:09:51 +0000

Hello, Po.

On Sun, Oct 16, 2022 at 15:20:49 +0800, Po Lu via CC-Mode-help wrote:
> Po Lu <luangruo <at> yahoo.com> writes:

> > Package: cc-mode

> > Sometimes, immediately before typing the closing parentheses of a
> > function invocation, like so:

> > void
> > dm_apply_screen_again (window, drawable, root_x, root_y)
> >      dm_root_window_ptr window;
> >      dm_root_window_drawable_ptr drawable;
> > {
> >   dm_lock_type type;
> >   dm_screen_ptr screen;
> > #if 1
> >   dm_tgs_reply_ptr client_data;
> > #else
> >   caddr_t client_data;
> > #endif
> >   dm_screen_lock_ptr lock;

> >   /* Private code elided.  */

> >   dm_apply_pointer_lock (window, lock

> > every occurrence of "lock", "root_x", and "root_y" in the file becomes
> > fontified as a type, and is stuck that way.  The only way to stop those
> > keywords from being fontified as types is by reenabling c-mode.

Just as a matter of interest, there's a testing hack in CC Mode for this.
Make some buffer change at (point-min), and c-found-types gets
reinitialised.  Maybe I should turn this into a proper command.

> > This did not happen in Emacs 28; I can't reproduce the bug with a file
> > that I can share, but I will keep trying to make one.

> I think I have a reproducible recipe for this now, which I got while
> working on a completely different program.

> First, insert the following text in a buffer:

> RelativePointer *
> XLSeatGetRelativePointer (Seat *seat, struct wl_resource *resource)
> {
>   RelativePointer *relative_pointer;
>   SeatClientInfo *info;

>   /* Create a relative pointer object for the relative pointer
>      resource RESOURCE.  */

>   relative_pointer = XLCalloc (1, sizeof *relative_pointer);
>   info = CreateSeatClientInfo (wl_resource_get_client (resource));

>   /* Link the relative pointer onto the seat client info.  */
>   relative_pointer->next = info->relative_pointers.next;
>   relative_pointer->last = &info->relative_pointers;

>   /* Then, the seat.  */
>   relative_pointer->seat = seat;
>   RetainSeat (seat);
> }

> then, move to the end of the buffer.  Turn on electric-pair-mode and
> c-mode.  Type:

> v SPC o SPC i SPC d RET X L S e a t D e s t r o y R e l a t i v e P o i
> n t e r SPC ( R e l a t i v e P o i n t e r SPC * r e l a t i v e _ p o
> i n t e r C-e

> every occurrence `relative_pointer' will be refontified as a type, and
> become stuck that way.

Thanks for this recipe!  In the end, it turned out to be a flag that
wasn't getting initialised properly.  So after typing a type, it
sometimes stayed set for the next identifier, which became a type, too.

I hope the following patch will have fixed the problem, so would you
please do the usual thing with the patch, and let me know how well the
problem has been fixed.  Thanks!



diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
index 2003b09ded..fc4e46633b 100644
--- a/lisp/progmodes/cc-mode.el
+++ b/lisp/progmodes/cc-mode.el
@@ -2080,13 +2080,14 @@ c-after-change-fix-comment-escapes
 (defun c-update-new-id (end)
   ;; Note the bounds of any identifier that END is in or just after, in
   ;; `c-new-id-start' and `c-new-id-end'.  Otherwise set these variables to
-  ;; nil.
+  ;; nil.  Set `c-new-id-is-type' unconditionally to nil.
   (save-excursion
     (goto-char end)
     (let ((id-beg (c-on-identifier)))
       (setq c-new-id-start id-beg
 	    c-new-id-end (and id-beg
-			      (progn (c-end-of-current-token) (point)))))))
+			      (progn (c-end-of-current-token) (point)))
+	    c-new-id-is-type nil))))
 
 (defun c-post-command ()
   ;; If point was inside of a new identifier and no longer is, record that



-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 58537 <at> debbugs.gnu.org
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Mon, 17 Oct 2022 09:34:19 +0800

Alan Mackenzie <acm <at> muc.de> writes:

> I hope the following patch will have fixed the problem, so would you
> please do the usual thing with the patch, and let me know how well the
> problem has been fixed.  Thanks!

It seems to be gone now.  Thanks for the fix.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 58537 <at> debbugs.gnu.org
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Mon, 17 Oct 2022 14:24:59 +0800

Alan Mackenzie <acm <at> muc.de> writes:

> diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
> index 2003b09ded..fc4e46633b 100644
> --- a/lisp/progmodes/cc-mode.el
> +++ b/lisp/progmodes/cc-mode.el
> @@ -2080,13 +2080,14 @@ c-after-change-fix-comment-escapes
>  (defun c-update-new-id (end)
>    ;; Note the bounds of any identifier that END is in or just after, in
>    ;; `c-new-id-start' and `c-new-id-end'.  Otherwise set these variables to
> -  ;; nil.
> +  ;; nil.  Set `c-new-id-is-type' unconditionally to nil.
>    (save-excursion
>      (goto-char end)
>      (let ((id-beg (c-on-identifier)))
>        (setq c-new-id-start id-beg
>  	    c-new-id-end (and id-beg
> -			      (progn (c-end-of-current-token) (point)))))))
> +			      (progn (c-end-of-current-token) (point)))
> +	    c-new-id-is-type nil))))
>  
>  (defun c-post-command ()
>    ;; If point was inside of a new identifier and no longer is, record that

BTW, there is still another case that isn't fixed: place the following
text in a C mode buffer:

{
  Data *tem;

  for (tem = surface->items; tem; tem = tem->next)
    {
      if (tem->type == tem)
	return tem;
    }

  /* Next, allocate some new client data.  */

  test->a = b;
}

and move point to the line above "test->a = b", and type

  TAB t e m SPC = SPC foo ;

"tem" will become fontified as a type, and will also be stuck that way.

Thanks.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 58537 <at> debbugs.gnu.org, acm <at> muc.de
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Mon, 17 Oct 2022 16:19:08 +0000

Hello, Po.

On Mon, Oct 17, 2022 at 14:24:59 +0800, Po Lu wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

[ .... ]

> BTW, there is still another case that isn't fixed: place the following
> text in a C mode buffer:

> {
>   Data *tem;

>   for (tem = surface->items; tem; tem = tem->next)
>     {
>       if (tem->type == tem)
> 	return tem;
>     }

>   /* Next, allocate some new client data.  */

>   test->a = b;
> }

> and move point to the line above "test->a = b", and type

>   TAB t e m SPC = SPC foo ;

> "tem" will become fontified as a type, and will also be stuck that way.

Thanks for taking the trouble to report this.

The problem is C Mode prematurely recognising tem in "tem \n test" as a
type, since there are two adjacent identifiers.

Please try out the following patch (which also includes yesterday's
change).  It also aims to solve the same problem when instead of

    test->a = b;

there is

    test (foo);

..

> Thanks.

Does this patch, together with that for bug #58534 also solve #58539, or
is that still giving trouble?

Here is the patch:



diff -r 0e4b43dec11c cc-engine.el
--- a/cc-engine.el	Fri Oct 14 17:13:47 2022 +0000
+++ b/cc-engine.el	Mon Oct 17 15:29:55 2022 +0000
@@ -9123,7 +9123,9 @@
       (when (eq name-res t)
 	;; In many languages the name can be used without the
 	;; prefix, so we add it to `c-found-types'.
-	(c-add-type pos (point))
+	(c-add-type pos (save-excursion
+			  (c-backward-syntactic-ws)
+			  (point)))
 	(when (and c-record-type-identifiers
 		   c-last-identifier-range)
 	  (c-record-type-id c-last-identifier-range)))
@@ -9208,7 +9210,10 @@
 	     (goto-char id-end)
 	     (if (or res c-promote-possible-types)
 		 (progn
-		   (c-add-type id-start id-end)
+		   (c-add-type id-start (save-excursion
+					  (goto-char id-end)
+					  (c-backward-syntactic-ws)
+					  (point)))
 		   (when (and c-record-type-identifiers id-range)
 		     (c-record-type-id id-range))
 		   (unless res
@@ -10777,8 +10782,16 @@
 			 (setq backup-if-not-cast t)
 			 (throw 'at-decl-or-cast t)))
 
-		     (setq backup-if-not-cast t)
-		     (throw 'at-decl-or-cast t)))
+		     ;; If we're in declaration or template delimiters, or one
+		     ;; of a certain set of characters follows, we've got a
+		     ;; type and variable.
+		     (if (or (memq context '(decl <>))
+			     (memq (char-after) '(?\; ?, ?= ?\( ?{ ?:)))
+			 (progn
+			   (setq backup-if-not-cast t)
+			   (throw 'at-decl-or-cast t))
+		       ;; We're probably just typing a statement.
+		       (throw 'at-decl-or-cast nil))))
 
 		 ;; CASE 4
 		 (when (and got-suffix
@@ -10894,8 +10907,13 @@
 
 	 ;; CASE 10
 	 (when at-decl-or-cast
-	   ;; By now we've located the type in the declaration that we know
-	   ;; we're in.
+	   ;; By now we've located the type in the declaration that we think
+	   ;; we're in.  Do we have enough evidence to promote the putative
+	   ;; type to a found type?  The user may be halfway through typing
+	   ;; a statement beginning with an identifier.
+	   (when (and (eq at-type 'maybe)
+		      (not (eq context 'top)))
+	     (setq c-record-type-identifiers nil))
 	   (throw 'at-decl-or-cast t))
 
 	 ;; CASE 11
diff -r 0e4b43dec11c cc-fonts.el
--- a/cc-fonts.el	Fri Oct 14 17:13:47 2022 +0000
+++ b/cc-fonts.el	Mon Oct 17 15:29:55 2022 +0000
@@ -1200,8 +1200,21 @@
   ;; arguments lists (i.e. lists enclosed by <...>) is more strict about what
   ;; characters it allows within the list.
   (let ((type (and (> match-pos (point-min))
-		   (c-get-char-property (1- match-pos) 'c-type))))
-    (cond ((not (memq (char-before match-pos) '(?\( ?, ?\[ ?< ?{)))
+		   (c-get-char-property (1- match-pos) 'c-type)))
+	id-pos)
+    (cond 
+     ;; Are we just after something like "(foo((bar))" ?
+     ((and (eq (char-before match-pos) ?\))
+	   (c-go-list-backward match-pos)
+	   (progn
+	     (c-backward-syntactic-ws)
+	     (and (setq id-pos (c-on-identifier))
+		  (goto-char id-pos)
+		  (progn
+		    (c-backward-syntactic-ws)
+		    (eq (char-before) ?\()))))
+      (c-get-fontification-context (point) not-front-decl toplev))
+	  ((not (memq (char-before match-pos) '(?\( ?, ?\[ ?< ?{)))
 	   (cons (and toplev 'top) nil))
 	  ;; A control flow expression or a decltype
 	  ((and (eq (char-before match-pos) ?\()
diff -r 0e4b43dec11c cc-mode.el
--- a/cc-mode.el	Fri Oct 14 17:13:47 2022 +0000
+++ b/cc-mode.el	Mon Oct 17 15:29:55 2022 +0000
@@ -2066,13 +2066,14 @@
 (defun c-update-new-id (end)
   ;; Note the bounds of any identifier that END is in or just after, in
   ;; `c-new-id-start' and `c-new-id-end'.  Otherwise set these variables to
-  ;; nil.
+  ;; nil.  Set `c-new-id-is-type' unconditionally to nil.
   (save-excursion
     (goto-char end)
     (let ((id-beg (c-on-identifier)))
       (setq c-new-id-start id-beg
 	    c-new-id-end (and id-beg
-			      (progn (c-end-of-current-token) (point)))))))
+			      (progn (c-end-of-current-token) (point)))
+	    c-new-id-is-type nil))))
 
 (defun c-post-command ()
   ;; If point was inside of a new identifier and no longer is, record that


-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 58537 <at> debbugs.gnu.org
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Tue, 18 Oct 2022 09:04:23 +0800

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Po.
>
> On Mon, Oct 17, 2022 at 14:24:59 +0800, Po Lu wrote:
>> Alan Mackenzie <acm <at> muc.de> writes:
>
> [ .... ]
>
>> BTW, there is still another case that isn't fixed: place the following
>> text in a C mode buffer:
>
>> {
>>   Data *tem;
>
>>   for (tem = surface->items; tem; tem = tem->next)
>>     {
>>       if (tem->type == tem)
>> 	return tem;
>>     }
>
>>   /* Next, allocate some new client data.  */
>
>>   test->a = b;
>> }
>
>> and move point to the line above "test->a = b", and type
>
>>   TAB t e m SPC = SPC foo ;
>
>> "tem" will become fontified as a type, and will also be stuck that way.
>
> Thanks for taking the trouble to report this.
>
> The problem is C Mode prematurely recognising tem in "tem \n test" as a
> type, since there are two adjacent identifiers.
>
> Please try out the following patch (which also includes yesterday's
> change).  It also aims to solve the same problem when instead of
>
>     test->a = b;
>
> there is
>
>     test (foo);
>
> ..
>
>> Thanks.
>
> Does this patch, together with that for bug #58534 also solve #58539, or
> is that still giving trouble?

Could you please send it as an attachment instead?  Thanks.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 58537 <at> debbugs.gnu.org, acm <at> muc.de
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Tue, 18 Oct 2022 08:02:24 +0000

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

Hello, Po.

On Tue, Oct 18, 2022 at 09:04:23 +0800, Po Lu wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

[ .... ]

> > Please try out the following patch (which also includes yesterday's
> > change).  It also aims to solve the same problem when instead of

> > Does this patch, together with that for bug #58534 also solve #58539, or
> > is that still giving trouble?

> Could you please send it as an attachment instead?  Thanks.

OK, attached.  What problems does an inline patch cause?

-- 
Alan Mackenzie (Nuremberg, Germany).

[diff.20221017.diff (text/plain, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 58537 <at> debbugs.gnu.org
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Wed, 19 Oct 2022 09:03:11 +0800

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Po.
>
> On Tue, Oct 18, 2022 at 09:04:23 +0800, Po Lu wrote:
>> Alan Mackenzie <acm <at> muc.de> writes:
>
> [ .... ]
>
>> > Please try out the following patch (which also includes yesterday's
>> > change).  It also aims to solve the same problem when instead of
>
>> > Does this patch, together with that for bug #58534 also solve #58539, or
>> > is that still giving trouble?
>
>> Could you please send it as an attachment instead?  Thanks.
>
> OK, attached.

Thanks, but now I get:

<stdin>:73: trailing whitespace.
    (cond 
error: patch failed: lisp/progmodes/cc-engine.el:9123
error: lisp/progmodes/cc-engine.el: patch does not apply

> What problems does an inline patch cause?

It gets turned into HTML due to the presence of ":)" in its contents.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 58537 <at> debbugs.gnu.org
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Wed, 19 Oct 2022 09:40:07 +0000

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

Hello, Po.

On Wed, Oct 19, 2022 at 09:03:11 +0800, Po Lu wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > On Tue, Oct 18, 2022 at 09:04:23 +0800, Po Lu wrote:
> >> Alan Mackenzie <acm <at> muc.de> writes:

> > [ .... ]

> >> > Please try out the following patch (which also includes yesterday's
> >> > change).  It also aims to solve the same problem when instead of

> >> > Does this patch, together with that for bug #58534 also solve #58539, or
> >> > is that still giving trouble?

> >> Could you please send it as an attachment instead?  Thanks.

> > OK, attached.

> Thanks, but now I get:

> <stdin>:73: trailing whitespace.
>     (cond 
> error: patch failed: lisp/progmodes/cc-engine.el:9123
> error: lisp/progmodes/cc-engine.el: patch does not apply

Apologies.  I'd committed the fix for bug #58534 after creating the
patch, and forgot about that.

I attach a corrected patch, which should now apply cleanly.

> > What problems does an inline patch cause?

> It gets turned into HTML due to the presence of ":)" in its contents.

What a wierd mail-reader!

I think the patch solves #58537 together with the problems you reported
since.  Does it also solve #58539?

-- 
Alan Mackenzie (Nuremberg, Germany).

[diff.20221019.diff (text/plain, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 58537 <at> debbugs.gnu.org
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Wed, 19 Oct 2022 18:27:34 +0800

Alan Mackenzie <acm <at> muc.de> writes:

> I think the patch solves #58537 together with the problems you reported
> since.  Does it also solve #58539?

Yes, it does, but there's still an unsolved problem:

test ()
{
  dm_window_ptr window;

  window = id_private_fetch ();
  if (window)
}

if this is edited into:

test ()
{
  dm_window_ptr window;

  window = id_private_fetch ();
  if ((window)addr window)
}

which is not valid C, but still something that can happen while typing a
program, and it is then edited into:

test ()
{
  dm_window_ptr window;

  window = id_private_fetch ();
  if ((window_addr) window)
}

"window" in the line above the "if" remains fontified as a type.

Thanks.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 58537 <at> debbugs.gnu.org, acm <at> muc.de
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Wed, 19 Oct 2022 12:47:07 +0000

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

Hello again, Po.

On Wed, Oct 19, 2022 at 18:27:34 +0800, Po Lu wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > I think the patch solves #58537 together with the problems you reported
> > since.  Does it also solve #58539?

> Yes, it does, ....

That's fantastic!

>  .... but there's still an unsolved problem:

> test ()
> {
>   dm_window_ptr window;

>   window = id_private_fetch ();
>   if (window)
> }

> if this is edited into:

> test ()
> {
>   dm_window_ptr window;

>   window = id_private_fetch ();
>   if ((window)addr window)
> }

> which is not valid C, but still something that can happen while typing a
> program, and it is then edited into:

> test ()
> {
>   dm_window_ptr window;

>   window = id_private_fetch ();
>   if ((window_addr) window)
> }

> "window" in the line above the "if" remains fontified as a type.

Sorry, you mentioned this before, and I didn't get around to fixing it.

Would you please try applying the attached patch on top of the earlier
patch from this morning (for me)/afternoon (for you).

If this works OK, then I propose linking bugs #58537 and #58539 and
closing them.  Thanks for being so patient and insistent over the last
few days.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

[diff.20221019b.diff (text/plain, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 58537 <at> debbugs.gnu.org
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Wed, 19 Oct 2022 21:14:50 +0800

Alan Mackenzie <acm <at> muc.de> writes:

> If this works OK, then I propose linking bugs #58537 and #58539 and
> closing them.  Thanks for being so patient and insistent over the last
> few days.

Yes, it seems to work fine here.  And on the contrary, I should thank
*you* for being so patient and responsive instead :)

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

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: acm <at> muc.de, 58537-done <at> debbugs.gnu.org
Subject: Re: bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as
 types at random
Date: Wed, 19 Oct 2022 15:07:02 +0000

Hello, Po.

On Wed, Oct 19, 2022 at 21:14:50 +0800, Po Lu wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > If this works OK, then I propose linking bugs #58537 and #58539 and
> > closing them.  Thanks for being so patient and insistent over the last
> > few days.

> Yes, it seems to work fine here.  And on the contrary, I should thank
> *you* for being so patient and responsive instead :)

That's good, thanks.  I've committed the patch, and I'm closing the bug
with this post.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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