cc-mode-help — Bug reports, feature requests, and general talk about CC Mode.

bug#80267: CC Mode 5.35.2 (C/*l); C mode comment in signature indentation regression

[Arsen A. <ar...@aa...>]

Alan Mackenzie <ac...@mu...> writes:

> Does it?  I don't think L X+1 does affect L X.  Maybe there's something
> coincidental in some test cases.

Ah, you're right!  I just figured out what happened.

1. Enable electric-pair-local-mode
2. Type, without leading whitespace (naturally):

   int foo (int a,
            /* hello */
            int b)

Upon reaching '(', electric-pair will insert ')', and as you keep
typing, it will be carried to the new line.  So, when the comment is
opened or closed, the indent engine sees that and figures "ah! there's
more text on this line, I'm a leading comment" and reindents
accordingly.

So, my initial description was indeed incorrect.  Sorry about that.

> I've committed the patch to CC Mode, thanks.
>
>> It may be wise to drop in some tests of both leading and non-leading
>> comments.  This should prevent future regressions.
>
> I've added a new test case to the CC Mode test suite which tests these
> things.  It's called comments-12.c, and looks like this:
>
> #########################################################################
> int foobar (int a,
>   /* bar */ int b,
>             /* foo */
>             int c);
>
> int foobar (
> 	    /* foo */
>   /* bar */ int a,
>     /* b */ int b,
> 	    int c);
>
> /* Local Variables: */
> /* c-file-offsets: ((arglist-intro . c-lineup-arglist-intro-after-paren)) */
> /* End: */
> #########################################################################

Shouldn't have doubted you!  That's nice :-)
-- 
Arsen Arsenović

bug#80267: CC Mode 5.35.2 (C/*l); C mode comment in signature indentation regression

[Alan M. <ac...@mu...>]

Hello, Arsen.

On Thu, Jan 29, 2026 at 15:21:31 +0100, Arsen Arsenović wrote:
> Hi Alan,

> Alan Mackenzie <ac...@mu...> writes:

> > Here's a patch which should fix it.  It tidies up other aspects of the
> > "leading comment" handling, too.  Please try it out and let me know
> > how well it works.  Thanks!

> It does appear to work, though I found it slightly unintuitive at first
> that line X+1 affects indent at line X, I understand why, so I think
> this is fine.  Thank you so much!

Does it?  I don't think L X+1 does affect L X.  Maybe there's something
coincidental in some test cases.

I've committed the patch to CC Mode, thanks.

> It may be wise to drop in some tests of both leading and non-leading
> comments.  This should prevent future regressions.

I've added a new test case to the CC Mode test suite which tests these
things.  It's called comments-12.c, and looks like this:

#########################################################################
int foobar (int a,
  /* bar */ int b,
            /* foo */
            int c);

int foobar (
	    /* foo */
  /* bar */ int a,
    /* b */ int b,
	    int c);

/* Local Variables: */
/* c-file-offsets: ((arglist-intro . c-lineup-arglist-intro-after-paren)) */
/* End: */
#########################################################################

> > Incidentally, I am no longer part of the Emacs project, so I don't
> > commit changes there any more.  The patch is based on the CC Mode
> > repository head at https://hg.savannah.nongnu.org/hgweb/cc-mode, which
> > can be cloned from that address with $ hg clone.  It should work, more
> > or less, on the Emacs repository too.

> That is unfortunate.  I didn't quite follow the thread where you
> announced the departure (sorry, I'm sure you can understand, I'm quite
> busy still..).

> That is a massive loss for Emacs.  Hopefully they at least pull CC-mode
> changes.

Somebody will need persuading to do this.

> Thank you once again, have a lovely day!

And yourself, too!

> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#80267: CC Mode 5.35.2 (C/*l); C mode comment in signature indentation regression

[Arsen A. <ar...@aa...>]

Hi Alan,

Alan Mackenzie <ac...@mu...> writes:

> Here's a patch which should fix it.  It tidies up other aspects of the
> "leading comment" handling, too.  Please try it out and let me know
> how well it works.  Thanks!

It does appear to work, though I found it slightly unintuitive at first
that line X+1 affects indent at line X, I understand why, so I think
this is fine.  Thank you so much!

It may be wise to drop in some tests of both leading and non-leading
comments.  This should prevent future regressions.

> Incidentally, I am no longer part of the Emacs project, so I don't
> commit changes there any more.  The patch is based on the CC Mode
> repository head at https://hg.savannah.nongnu.org/hgweb/cc-mode, which
> can be cloned from that address with $ hg clone.  It should work, more
> or less, on the Emacs repository too.

That is unfortunate.  I didn't quite follow the thread where you
announced the departure (sorry, I'm sure you can understand, I'm quite
busy still..).

That is a massive loss for Emacs.  Hopefully they at least pull CC-mode
changes.

Thank you once again, have a lovely day!
-- 
Arsen Arsenović

bug#80267: CC Mode 5.35.2 (C/*l); C mode comment in signature indentation regression

[Alan M. <ac...@mu...>]

Hello again, Arsen.

On Mon, Jan 26, 2026 at 17:07:17 +0100, Arsen Arsenović via CC-Mode-help wrote:
> Package: cc-mode

> <#secure method=pgpmime mode=sign>
> Package: cc-mode

> In a c-mode buffer, insert the following:

>   int foo(int a,
>   /* foo */
>   int b);

> ... then, reindent the whole buffer (M-h <TAB>).

> In Emacs 29, this indented, correctly, as:

>   int foo(int a,
>           /* foo */
>           int b);

> ... and in Emacs 31, this indents as:

>   int foo(int a,
>   /* foo */
>           int b);

> Not sure how long this has been happening, but it's probably a few
> weeks, since my dev build (which is behind, at
> 3945654f05629c620b2b404a289a969d501ee285) is seeing the same.

The cause of this bug was the strategy used to indent leading comments,
so that

    int foobar(int a,
       /* b */ int b,
       .....

would get indented as shown, rather than /* b */ being indented under
int a;.  Unfortunately, this failed to take account of comment only
lines, which also got pushed to the left.

Here's a patch which should fix it.  It tidies up other aspects of the
"leading comment" handling, too.  Please try it out and let me know how
well it works.  Thanks!

Incidentally, I am no longer part of the Emacs project, so I don't
commit changes there any more.  The patch is based on the CC Mode
repository head at https://hg.savannah.nongnu.org/hgweb/cc-mode, which
can be cloned from that address with $ hg clone.  It should work, more
or less, on the Emacs repository too.

> TIA, have a lovely day, and happy new year!  :-)

> Emacs  : GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.51, cairo version 1.18.4)
>  of 2026-01-23
> Package: CC Mode 5.35.2 (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)


diff -r ff81967283a6 cc-align.el
--- a/cc-align.el	Fri Sep 19 20:30:07 2025 +0000
+++ b/cc-align.el	Thu Jan 29 11:40:31 2026 +0000
@@ -182,6 +182,19 @@
       (c-safe-position (or containing-sexp (point)) c-state-cache)
       containing-sexp))))
 
+(defun c-leading-comment-length ()
+  "Return the length of any comments preceding the first token.
+This length extends from beginning of indentation to the first
+non-comment character on the line.  If there are no such comments, or
+only comments on the line, return 0."
+  (save-excursion
+    (back-to-indentation)
+    (let ((ind-col (current-column)))
+      (c-forward-comments (c-point 'eol))
+      (if (eolp)
+	  0
+	(- (current-column) ind-col)))))
+
 (defun c-lineup-arglist (_langelem)
   "Line up the current argument line under the first argument.
 
@@ -203,11 +216,7 @@
 Works with: arglist-cont-nonempty, arglist-close."
   (save-excursion
     (let ((indent-pos (point))
-	  (ws-length (save-excursion
-		       (back-to-indentation)
-		       (let ((ind-col (current-column)))
-			 (c-forward-comments (c-point 'eol))
-			 (- (current-column) ind-col)))))
+	  (leading-comment-len (c-leading-comment-length)))
 
       (if (c-block-in-arglist-dwim (c-langelem-2nd-pos c-syntactic-element))
 	  c-basic-offset		; DWIM case.
@@ -227,7 +236,7 @@
 	    (c-forward-comments (c-point 'eol))
 	    (if (eolp)
 		(goto-char arglist-content-start)))
-	  (vector (- (current-column) ws-length)))))))
+	  (vector (- (current-column) leading-comment-len)))))))
 
 (defun c-lineup-argcont-1 (elem)
   ;; Move to the start of the current arg and return non-nil, otherwise
@@ -321,6 +330,25 @@
       (c-forward-syntactic-ws)
       (vector (+ (current-column) c-basic-offset)))))
 
+(defun c-lineup-arglist-cont (_langelem)
+  "Indent an arglist-cont line under the previous argument.
+\"Ignore\" leading comments.
+
+int foobar (
+    /* a */ int a,
+  /* baz */ int b,              <- c-lineup-arglist-cont
+            /* empty */         <- c-lineup-arglist-cont
+            int c);             <- c-lineup-arglist-cont
+
+Works with: arglist-cont."
+  (let ((leading-comment-len (c-leading-comment-length))
+	anchor-comment-len anchor-col)
+    (save-excursion
+      (goto-char (c-langelem-pos c-syntactic-element))
+      (setq anchor-comment-len (c-leading-comment-length))
+      (setq anchor-col (current-column)))
+    (vector (- (+ anchor-col anchor-comment-len) leading-comment-len))))
+
 (defun c-lineup-arglist-intro-after-paren (_langelem)
   "Line up a line to just after the open paren of the surrounding paren
 or brace block.
@@ -328,19 +356,15 @@
 Works with: defun-block-intro, brace-list-intro, enum-intro
 statement-block-intro, statement-case-intro, arglist-intro."
   (save-excursion
-    (let ((ws-length (save-excursion
-		       (back-to-indentation)
-		       (let ((ind-col (current-column)))
-			 (c-forward-comments (c-point 'eol))
-			 (- (current-column) ind-col)))))
-    (beginning-of-line)
-    (backward-up-list 1)
-    (forward-char)
-    (let ((after-paren-pos (point)))
-      (c-forward-comments (c-point 'eol))
-      (if (eolp)
-	  (goto-char after-paren-pos)))
-    (vector (- (current-column) ws-length)))))
+    (let ((ws-length (c-leading-comment-length)))
+      (beginning-of-line)
+      (backward-up-list 1)
+      (forward-char)
+      (let ((after-paren-pos (point)))
+	(c-forward-comments (c-point 'eol))
+	(if (eolp)
+	    (goto-char after-paren-pos)))
+      (vector (- (current-column) ws-length)))))
 
 (defun c-lineup-item-after-paren-at-boi (_langelem)
   "Line up to just after the surrounding open paren at boi.
diff -r ff81967283a6 cc-mode.texi
--- a/cc-mode.texi	Fri Sep 19 20:30:07 2025 +0000
+++ b/cc-mode.texi	Thu Jan 29 11:40:31 2026 +0000
@@ -37,8 +37,8 @@
 version with cross references pointing to the GNU Emacs manuals,
 the second with them pointing to the XEmacs manuals.
     ## Info output
-    makeinfo cc-mode.texi
-    makeinfo -DXEMACS cc-mode.texi
+    makeinfo --no-split cc-mode.texi
+    makeinfo --no-split -DXEMACS cc-mode.texi
 
     ## DVI output
     ## You may need to set up the environment variable TEXINPUTS so
@@ -6145,6 +6145,10 @@
 @findex lineup-arglist (c-)
 Line up the current argument line under the first argument.
 
+If there are any comments at the start of the line, this function will
+attempt to line up the argument correctly, with the comment appearing
+to the left of that argument.
+
 As a special case, if an argument on the same line as the open
 parenthesis starts with a brace block opener, the indentation is
 @code{c-basic-offset} only.  This is intended as a ``DWIM'' measure in
@@ -6169,6 +6173,29 @@
 
 @comment ------------------------------------------------------------
 
+@defun c-lineup-arglist-cont
+@findex lineup-arglist-cont (c-)
+Line up an arglist-cont line under the previous argument.
+
+If there are any comments at the start of the line, this function will
+attempt to line up the argument correctly, with the comment appearing
+to the left of that argument.
+
+@example
+@group
+int foobar (
+    /* a */ int a,
+  /* baz */ int b,              @hereFn{c-lineup-arglist-cont}
+            /* empty */         @hereFn{c-lineup-arglist-cont}
+            int c);             @hereFn{c-lineup-arglist-cont}
+@end group
+@end example
+
+@workswith @code{arglist-cont}.
+@end defun
+
+@comment ------------------------------------------------------------
+
 @defun c-lineup-arglist-intro-after-paren
 @findex lineup-arglist-intro-after-paren (c-)
 Line up a line to just after the open paren of the surrounding paren or
diff -r ff81967283a6 cc-vars.el
--- a/cc-vars.el	Fri Sep 19 20:30:07 2025 +0000
+++ b/cc-vars.el	Thu Jan 29 11:40:31 2026 +0000
@@ -1382,7 +1382,7 @@
        (arglist-intro         . +)
        ;; Anchor pos: At the containing statement(*).
        ;; 2nd pos: At the open paren.
-       (arglist-cont          . (c-lineup-gcc-asm-reg 0))
+       (arglist-cont          . (c-lineup-gcc-asm-reg c-lineup-arglist-cont))
        ;; Anchor pos: At the first token after the open paren.
        (arglist-cont-nonempty . (c-lineup-gcc-asm-reg c-lineup-arglist))
        ;; Anchor pos: At the containing statement(*).

[ .... ]

> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#80267: CC Mode 5.35.2 (C/*l); C mode comment in signature indentation regression

[Alan M. <ac...@mu...>]

Hello, Arsen.

Thanks for the bug report!

On Mon, Jan 26, 2026 at 17:07:17 +0100, Arsen Arsenović via CC-Mode-help wrote:
> Package: cc-mode

> <#secure method=pgpmime mode=sign>
> Package: cc-mode

> In a c-mode buffer, insert the following:

>   int foo(int a,
>   /* foo */
>   int b);

> ... then, reindent the whole buffer (M-h <TAB>).

> In Emacs 29, this indented, correctly, as:

>   int foo(int a,
>           /* foo */
>           int b);

> ... and in Emacs 31, this indents as:

>   int foo(int a,
>   /* foo */
>           int b);

> Not sure how long this has been happening, but it's probably a few
> weeks, since my dev build (which is behind, at
> 3945654f05629c620b2b404a289a969d501ee285) is seeing the same.

I'll have a look at this, yes.  It might be one of these bugs which on
being solved, opens up a problem elsewhere.  I hope not!

Ulrich Müller has pinpointed the patch which introduced the bug.
Thanks, Ulrich!

> TIA, have a lovely day, and happy new year!  :-)

[ .... ]

> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#80267: CC Mode 5.35.2 (C/*l); C mode comment in signature indentation regression

[Ulrich M. <ul...@ge...>]

Bisection points to this commit as the culprit:

https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?id=555ec43a32ea8f3675c5a9d73ca30609eeaa9013
commit 555ec43a32ea8f3675c5a9d73ca30609eeaa9013
Author: Alan Mackenzie <ac...@mu...>
Date:   Thu Mar 27 10:24:48 2025 +0000

    C++ Mode: Fix some indentation bugs.  FIxes bug#19867

bug#80267: CC Mode 5.35.2 (C/*l); C mode comment in signature indentation regression

[Arsen A. <ar...@aa...>]

Package: cc-mode

<#secure method=pgpmime mode=sign>
Package: cc-mode

In a c-mode buffer, insert the following:

  int foo(int a,
  /* foo */
  int b);

... then, reindent the whole buffer (M-h <TAB>).

In Emacs 29, this indented, correctly, as:

  int foo(int a,
          /* foo */
          int b);

... and in Emacs 31, this indents as:

  int foo(int a,
  /* foo */
          int b);

Not sure how long this has been happening, but it's probably a few
weeks, since my dev build (which is behind, at
3945654f05629c620b2b404a289a969d501ee285) is seeing the same.

TIA, have a lovely day, and happy new year!  :-)

Emacs  : GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.51, cairo version 1.18.4)
 of 2026-01-23
Package: CC Mode 5.35.2 (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
 c-lineup-template-args-indented-from-margin)
		   (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)
		   (enum-entry . 0)
		   (enum-intro c-lineup-item-after-paren-at-boi +)
		   (enum-close . 0)
		   (enum-open . class-open)
		   (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 . +)
		   (class-field-cont . c-lineup-class-field-cont)
		   (member-init-cont . c-lineup-multi-inher)
		   (member-init-intro . +)
		   (annotation-var-cont . +)
		   (annotation-top-cont . 0)
		   (constraint-cont c-lineup-item-after-paren-at-boi +)
		   (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-close-under-paren)
		   (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
 comment-multi-line t
 comment-start-skip "\\(?://+\\|/\\*+\\)\\s *"
 fill-prefix nil
 fill-column 79
 paragraph-start "[ 	]*\\(//+\\|\\**\\)[ 	]*$\\|^\f"
 adaptive-fill-mode t
 adaptive-fill-regexp "[ 	]*\\(//+\\|\\**\\)[ 	]*\\([-–!|#%;>*·•‣⁃◦ 	]*\\)"
 )

-- 
Arsen Arsenović

Nested indentation for preprocessor directives like #if

[R. D. <rdi...@rd...>]

Hi all:

I have been playing with 'c-toggle-cpp-indent-to-body', but it is not enough, I would like to have nested indentation like:

#if AAA
   #if BBB
     ...
   #else
     ...
   #endif
#else
   #if CCC
     ...
   #else
     ...
   #endif
#endif

I gather that is not possible with the current implementation, right?

I am not the first to come up with such a wish:

https://emacs.stackexchange.com/questions/76465/how-to-configure-emacs-to-support-indented-c-preprocessor-statements

At the very least, it would be nice if the documentation for 'c-toggle-cpp-indent-to-body' mentioned that this often-expected indentation does not work.


By the way, on this web page:

https://cc-mode.sourceforge.net/

There is a "Mailing lists" link like this:

https://cc-mode.sourceforge.net/lists.php

But that URL just redirects back to https://cc-mode.sourceforge.net/ , and there is no mention of this mailing list cc-...@li... .

Thanks in advance,
   rdiez

Re: Wrong version number, oudated "upstream", dead link to GNU Indent and outdated manual

[Alan M. <ac...@mu...>]

Hello, Ana.

On Thu, Oct 30, 2025 at 02:00:53 +0000, ana--- via CC-Mode-help wrote:
> Heya, cc-mode.el says the current cc-mode version is 5.33.1, whereas
> cc-defs.el says it is 5.35.2

Thanks.  I wasn't aware of the 5.33.1 in cc-mode.el.  I didn't add it,
and the person who did didn't tell me about it.  I'll fix that.

> Also, the documentation says to go to https://www.nongnu.org/cc-mode
> in order to update to a newer version, but the code available over
> there isn't up to date with the state of cc-mode in the emacs repo.

Standalone CC Mode is kept compatible with older Emacsen and also
XEmacs.  So it lacks some of the more modern features which have been
introduced into Emacs recently.

They have different version numbers, so that when a bug is reported, I
know in which flavour of CC Mode the bug has arisen.

Otherwise, the CC Mode is at the same state in Emacs and standalone.

> Additionally, the nongnu manual provides an incorrect link for gnu
> Indent.

Thanks for pointing that out, I've fixed it.  For a long time, there was
no online manual for GNU indent, but there is now.

> Lastly, "class-field-cont" was added 7 months ago but the manual on
> gnu.org hasn't been updated since february (8 months ago), it makes it
> harder to discover this symbol.

I'm not sure what you mean by "gnu.org".  Both the Emacs repository
(master branch) and the CC Mode repository were updated in cc-mode.texi
last March when the change to the .el files was committed.

Could it be there's a copy of cc-mode.info on https://www.gnu.org
somewhere that I don't know about?

> Have a great day ^v^

Thanks, yourself too.

-- 
Alan Mackenzie (Nuremberg, Germany).

Wrong version number, oudated "upstream", dead link to GNU Indent and outdated manual

[<an...@ki...>]

Heya, cc-mode.el says the current cc-mode version is 5.33.1, whereas  cc-defs.el says it is 5.35.2

Also, the documentation says to go to https://www.nongnu.org/cc-mode in order to update to a newer version, but the code available over there isn't up to date with the state of cc-mode in the emacs repo.

Additionally, the nongnu manual provides an incorrect link for gnu Indent.

Lastly, "class-field-cont" was added 7 months ago but the manual on gnu.org hasn't been updated since february (8 months ago), it makes it harder to discover this symbol.

Have a great day ^v^

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Mattias E. <mat...@gm...>]

30 apr. 2025 kl. 20.58 skrev Alan Mackenzie <ac...@mu...>:

> DONE.

Thank you!

Re: C23 support in CC Mode.

[Alan M. <ac...@mu...>]

Hello, Arsen.

As half-promised, I've committed a large CC Mode patch which is intended
to cover C23.  It is now in the Emacs master branch at savannah.

On Mon, Dec 23, 2024 at 11:19:37 +0100, Arsen Arsenović wrote:
> Hi Alan,

> Alan Mackenzie <ac...@mu...> writes:

[ .... ]

> >> > BTW, C has recently gained auto type deduction similar to C++

> > Yes.  What is the world coming to?  ;-)

> >> Seems that we forgot about this one!  Whoops.

> >> Could I ask for this one being applied too?

> > Certainly!  There are actually a few new things in C23 I need to attend
> > to.

[ .... ]

> > There's numbers like 1'000'000, for example.  That's already been
> > implemented for C++ Mode, so shouldn't be much trouble, but I need to
> > get down to this and do it systematically.  So give me just a little
> > time here, please.

> No worries!  I didn't mean to hurry you along, sorry!

If you could find time to download the latest master and give the C23
features a run through, that would be great.

Thanks!

> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Alan M. <ac...@mu...>]

Hello again, Mattias.

On Mon, Apr 21, 2025 at 20:35:22 +0000, Alan Mackenzie wrote:
> On Thu, Apr 17, 2025 at 15:42:59 +0200, Mattias Engdegård wrote:
> > Thank you for fixing this. A minor oversight in the committed patch, in cc-align.el:

> >  351        (skip-syntax-backward " \t([{" (c-point 'boi))

> > This call should probably use `skip-char-backward`, because `\t`, `[`, and `{` aren't syntax chars.
> > It currently works by accident because of the ` ` and `(` syntax classes.

> Thanks for spotting this and telling me about it.  I'll get around to
> fixing it in the next few days.

DONE.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug#77969: [PATCH] Add buttons to manuals in some commentary sections

[Eli Z. <el...@gn...>]

> From: Morgan Smith <Mor...@ou...>
> Date: Mon, 21 Apr 2025 13:54:47 -0400
> 
> Tags: patch
> 
> This patch will affect how a lot of packages get presented to the user.
> 
> Run `M-x package-list-packages'.
> 
> Now go down to 'use-package' and press the button (RET) to pull up the
> package summary.
> 
> At the bottom of that summary it says "See the `use-package' info manual
> for more information.".  The "`use-package'" bit is a button will take
> you to a Help buffer describing the macro.  This is not ideal as the
> sentence is talking about the Info manual.
> 
> After my change the sentence will change too "See Info node
> `(use-package)' for more information." where the "`(use-package)'" part
> is a button that takes you to the info manual.

If we want something like this at the beginning of each Lisp package,
we need to augment our conventions and tips to say that.

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Alan M. <ac...@mu...>]

Hello, Mattias.

On Thu, Apr 17, 2025 at 15:42:59 +0200, Mattias Engdegård wrote:
> Thank you for fixing this. A minor oversight in the committed patch, in cc-align.el:

>  351        (skip-syntax-backward " \t([{" (c-point 'boi))

> This call should probably use `skip-char-backward`, because `\t`, `[`, and `{` aren't syntax chars.
> It currently works by accident because of the ` ` and `(` syntax classes.

Thanks for spotting this and telling me about it.  I'll get around to
fixing it in the next few days.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#77969: [PATCH] Add buttons to manuals in some commentary sections

[Morgan S. <Mor...@ou...>]

Tags: patch

This patch will affect how a lot of packages get presented to the user.

Run `M-x package-list-packages'.

Now go down to 'use-package' and press the button (RET) to pull up the
package summary.

At the bottom of that summary it says "See the `use-package' info manual
for more information.".  The "`use-package'" bit is a button will take
you to a Help buffer describing the macro.  This is not ideal as the
sentence is talking about the Info manual.

After my change the sentence will change too "See Info node
`(use-package)' for more information." where the "`(use-package)'" part
is a button that takes you to the info manual.

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Mattias E. <mat...@gm...>]

Thank you for fixing this. A minor oversight in the committed patch, in cc-align.el:

 351        (skip-syntax-backward " \t([{" (c-point 'boi))

This call should probably use `skip-char-backward`, because `\t`, `[`, and `{` aren't syntax chars.
It currently works by accident because of the ` ` and `(` syntax classes.

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Stefan K. <ste...@gm...>]

Alan Mackenzie <ac...@mu...> writes:

> I've just committed a fix (a ~700 line patch ;-), so I think this bug is
> finally solved.

Thank you!

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Alan M. <ac...@mu...>]

Hello, Stefan.

On Tue, Mar 11, 2025 at 16:23:13 -0400, Stefan Kangas wrote:
> Alan Mackenzie <ac...@mu...> writes:

> > Yes, I'll do this.  Sorry I never replied to your post in 2020.  I
> > started looking at the bug then, but somehow didn't get very far with it.
> > Maybe it was because there were so many individual glitches in the
> > report.  Thanks for distilling the cases which still remain unfixed.

> Thanks!

I've just committed a fix (a ~700 line patch ;-), so I think this bug is
finally solved.

I'm closing the bug with this post.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Alan M. <ac...@mu...>]

Hello, Stefan.

On Tue, Mar 11, 2025 at 09:54:20 -0700, Stefan Kangas wrote:
> Stefan Kangas <ste...@gm...> writes:

> > Simon <tur...@gm...> writes:

> >> Initializer lists use curly braces, but their contents do not indent properly with emacs' c++-mode.
> >> In short, one may use an initializer list to declare and initialize a vector of integers as such:
> >>   std::vector<int> Foo( { 1, 2, 3, 4, 5 } );

> >> Problems arise when the elements of the list span on multiple line and it gets even worse when the elements are lambda-expressions
> >> and nested initializer lists.
> >> The following code illustrate most cases and related situations.  The code below compiles without error or warning with gcc 4.8.3.

> > I had a look at the fairly long example provided here, and AFAICT, the
> > indentation is incorrect in the below cases (trimmed down from the
> > original).  Some of the examples of incorrect indentation were already
> > fixed.

> > Alan, could you perhaps take a look at this and see if this is something
> > that is fixable?  Thanks in advance.

> Alan, any chance you could look into the below cases?  Thanks in advance.

Yes, I'll do this.  Sorry I never replied to your post in 2020.  I
started looking at the bug then, but somehow didn't get very far with it.
Maybe it was because there were so many individual glitches in the
report.  Thanks for distilling the cases which still remain unfixed.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Java var and final keywords [was: Re: [PATCH] Java assert keyword]

[Arsen A. <ar...@aa...>]

Hi Alan,

Alan Mackenzie <ac...@mu...> writes:

> Hello, Arsen.
>
> On Thu, Jan 02, 2025 at 21:09:26 +0100, Arsen Arsenović wrote:
>> Hi Alan,
>
>> Happy new year!
>
> And a HNY to yourself, too!
>
>> ... and sorry to bother you so early in 2025!
>
> No bother at all!
>
>> Arsen Arsenović <cc-...@li...> writes:
>
>> > I was referring to the patch, sorry for not being clear:
>
>> >   https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e
>
>> > ... it adds the relatively new 'var' keyword to the Java support.
>
>> Gentle ping on this:
>> https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e
>
>> It should be another easy patch to merge.
>
> Indeed it was, thanks!  I've committed it to all the usual places, and I
> think I've spelt your name correctly this time.

Thanks!  I just rebuilt Emacs and got it.

And yes, the name is fine this time :-)

Have a lovely day!
-- 
Arsen Arsenović

Java var and final keywords [was: Re: [PATCH] Java assert keyword]

[Alan M. <ac...@mu...>]

Hello, Arsen.

On Thu, Jan 02, 2025 at 21:09:26 +0100, Arsen Arsenović wrote:
> Hi Alan,

> Happy new year!

And a HNY to yourself, too!

> ... and sorry to bother you so early in 2025!

No bother at all!

> Arsen Arsenović <cc-...@li...> writes:

> > I was referring to the patch, sorry for not being clear:

> >   https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e

> > ... it adds the relatively new 'var' keyword to the Java support.

> Gentle ping on this:
> https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e

> It should be another easy patch to merge.

Indeed it was, thanks!  I've committed it to all the usual places, and I
think I've spelt your name correctly this time.

> Thanks in advance.

Thank you for the patch.

> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Java assert keyword

[Alan M. <ac...@mu...>]

Hello, Arsen.

Happy new year to you, too!

On Thu, Jan 02, 2025 at 21:09:26 +0100, Arsen Arsenović wrote:
> Hi Alan,

> Happy new year!

> ... and sorry to bother you so early in 2025!

> Arsen Arsenović <cc-...@li...> writes:

> > I was referring to the patch, sorry for not being clear:

> >   https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e

> > ... it adds the relatively new 'var' keyword to the Java support.

> Gentle ping on this:
> https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e

> It should be another easy patch to merge.

I'll get it seen to, soon.  I'll try to get the commit message correct
this time, too.  ;-)

> Thanks in advance.
> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH] Java assert keyword

[Arsen A. <ar...@aa...>]

Hi Alan,

Happy new year!

... and sorry to bother you so early in 2025!

Arsen Arsenović <cc-...@li...> writes:

> I was referring to the patch, sorry for not being clear:
>
>   https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e
>
> ... it adds the relatively new 'var' keyword to the Java support.

Gentle ping on this:
https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e

It should be another easy patch to merge.

Thanks in advance.
-- 
Arsen Arsenović

Re: [PATCH] Java assert keyword

[Arsen A. <ar...@aa...>]

Hi Alan,

Alan Mackenzie <ac...@mu...> writes:

>> > I just noticed the same about var and, similarly:
>> > https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e
>
>> > BTW, C has recently gained auto type deduction similar to C++
>
> Yes.  What is the world coming to?  ;-)
>
>> Seems that we forgot about this one!  Whoops.
>
>> Could I ask for this one being applied too?
>
> Certainly!  There are actually a few new things in C23 I need to attend
> to.

I was referring to the patch, sorry for not being clear:

  https://hg.sr.ht/~arsen/cc-mode/rev/ce95a9f9caa050602c107f61dbe933e31338674e

... it adds the relatively new 'var' keyword to the Java support.

> There's numbers like 1'000'000, for example.  That's already been
> implemented for C++ Mode, so shouldn't be much trouble, but I need to
> get down to this and do it systematically.  So give me just a little
> time here, please.

No worries!  I didn't mean to hurry you along, sorry!
-- 
Arsen Arsenović