GNU bug report logs - #73182
CC Mode 5.35.2 (C++//l); 'enum' and 'enum class' appear to not get parsed correctly for indentation

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 73182 in the body.
You can then email your comments to 73182 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: Arsen Arsenović <arsen <at> aarsen.me>
To: bug-gnu-emacs <at> gnu.org
Subject: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class' appear to not get
 parsed correctly for indentation
Date: Wed, 11 Sep 2024 20:52:15 +0200

Package: cc-mode

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

Hi again,

CC-mode appears to misindent enum and enum class:

  enum asda
    {
      asd
    };
  
  enum class asasdas
    {
      asda
    };

These should be indented same as struct per
https://www.gnu.org/prep/standards/html_node/Formatting.html#index-enum-types_002c-formatting
(well, enum class isn't mentioned, but I see no reason to act different,
and GCC appears to do this, so it'd be convenient to keep struct-like
formatting).

When using C-c C-s, it appears that C and C++ mode do not even recognize
enum as a class-open, instead doing brace-list-open.

Emacs  : GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.42, cairo version 1.18.0)
 of 2024-08-31
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)
		   (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)
		   (constraint-cont . +)
		   (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 'c-do-auto-fill
 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ć

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

From: Alan Mackenzie <acm <at> muc.de>
To: Arsen Arsenović <arsen <at> aarsen.me>
Cc: acm <at> muc.de, 73182 <at> debbugs.gnu.org
Subject: Re: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class'
 appear to not get parsed correctly for indentation
Date: Mon, 16 Sep 2024 11:45:00 +0000

Hello, Arsen.

Thanks for taking the trouble to raise this bug report last Wednesday.

On Wed, Sep 11, 2024 at 20:52:15 +0200, Arsen Arsenović via CC-Mode-help wrote:
> Package: cc-mode

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

> Hi again,

> CC-mode appears to misindent enum and enum class:

>   enum asda
>     {
>       asd
>     };
  
>   enum class asasdas
>     {
>       asda
>     };

Yes.

> These should be indented same as struct per
> https://www.gnu.org/prep/standards/html_node/Formatting.html#index-enum-types_002c-formatting
> (well, enum class isn't mentioned, but I see no reason to act different,
> and GCC appears to do this, so it'd be convenient to keep struct-like
> formatting).

Yes.

> When using C-c C-s, it appears that C and C++ mode do not even recognize
> enum as a class-open, instead doing brace-list-open.

Yes.  This bug has come up at least once before, on 19 February 2014, in a
post to bug-cc-mode <at> gnu.org from Xue Fuqiao, Subject: CC Mode 5.32.5
(C/l); The indentation of `enum' of the default `gnu' style is wrong?
After having considered the matter for some time, I answered on 3 March
2014 as follows:

    Even though there's a bug, it's been there for a _very_ long time
    (since before 1997), such a long time that it would cause chaos if
    it were to be fixed.  You can see many examples of this wrong enum
    indentation all through the Emacs C source, and probably throughout
    the entire GNU project.

    If this bug were to be fixed, inconsistent (even if correct)
    indentation would start creeping into thousands of files.  I think
    it's best left as it is, unsatisfactory though that be.

At the time, I opened a thread on emacs-devel, asking what other people
thought about the bug (Date: 3 March 2014, Subject: The indentation of
`enum' in the default `gnu' CC Mode style is wrong.)  Only one person
responded, Paul Eggert, saying he would be in favour of fixing the bug.

Ten years later, now, I still think that was the right decision to make,
and that the bug should remain unfixed.  If you have nothing against it,
I will close this bug as won't fix.

Sorry about this.

> Emacs  : GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.42, cairo version 1.18.0)
>  of 2024-08-31
> 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)

[ .... ]

> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Arsen Arsenović <arsen <at> aarsen.me>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 73182 <at> debbugs.gnu.org
Subject: Re: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class'
 appear to not get parsed correctly for indentation
Date: Tue, 17 Sep 2024 12:43:05 +0200

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

Hi Alan,

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

> Hello, Arsen.
>
> Thanks for taking the trouble to raise this bug report last Wednesday.
>
> On Wed, Sep 11, 2024 at 20:52:15 +0200, Arsen Arsenović via CC-Mode-help wrote:
>> Package: cc-mode
>
>> <#secure method=pgpmime mode=sign>
>> Package: cc-mode
>
>> Hi again,
>
>> CC-mode appears to misindent enum and enum class:
>
>>   enum asda
>>     {
>>       asd
>>     };
>   
>>   enum class asasdas
>>     {
>>       asda
>>     };
>
> Yes.
>
>> These should be indented same as struct per
>> https://www.gnu.org/prep/standards/html_node/Formatting.html#index-enum-types_002c-formatting
>> (well, enum class isn't mentioned, but I see no reason to act different,
>> and GCC appears to do this, so it'd be convenient to keep struct-like
>> formatting).
>
> Yes.
>
>> When using C-c C-s, it appears that C and C++ mode do not even recognize
>> enum as a class-open, instead doing brace-list-open.
>
> Yes.  This bug has come up at least once before, on 19 February 2014, in a
> post to bug-cc-mode <at> gnu.org from Xue Fuqiao, Subject: CC Mode 5.32.5
> (C/l); The indentation of `enum' of the default `gnu' style is wrong?
> After having considered the matter for some time, I answered on 3 March
> 2014 as follows:
>
>     Even though there's a bug, it's been there for a _very_ long time
>     (since before 1997), such a long time that it would cause chaos if
>     it were to be fixed.  You can see many examples of this wrong enum
>     indentation all through the Emacs C source, and probably throughout
>     the entire GNU project.
>
>     If this bug were to be fixed, inconsistent (even if correct)
>     indentation would start creeping into thousands of files.  I think
>     it's best left as it is, unsatisfactory though that be.

As a data point here, the correct indentation is present all over GCC
(which has people using everything from vi over notepad++ to VScode, and
naturally, Emacs), but it is mixed up, presumably partially as a result
of this bug, so I'd prefer if the editor would DTRT OOTB.

Also, if there is intention to use automatic code formatting tools,
which some have expressed as desirable for the toolchain projects (and I
don't disagree - helps people who aren't using Emacs to get indent right
easily ;-) ), having incorrect indentation by the editor will be
burdensome, as it'd result in the editor and formatter fighting often.

And, given that nobody (AFAIK) uses Emacs to mass-reindent code, I
suspect the fallout of a fix will be gradual and silent.

As an alternative to fixing this bug so that the token is recognized as
a struct, we could have a new token for enum that does get indented
correctly OOTB and that affected projects adjust to avoid trouble in
their codebases.

> At the time, I opened a thread on emacs-devel, asking what other people
> thought about the bug (Date: 3 March 2014, Subject: The indentation of
> `enum' in the default `gnu' CC Mode style is wrong.)  Only one person
> responded, Paul Eggert, saying he would be in favour of fixing the bug.
>
> Ten years later, now, I still think that was the right decision to make,
> and that the bug should remain unfixed.  If you have nothing against it,
> I will close this bug as won't fix.
>
> Sorry about this.

No problem - thanks for responding :-)

Have a lovely day.
-- 
Arsen Arsenović

[signature.asc (application/pgp-signature, inline)]

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

From: Alan Mackenzie <acm <at> muc.de>
To: Arsen Arsenović <arsen <at> aarsen.me>
Cc: acm <at> muc.de, 73182 <at> debbugs.gnu.org
Subject: Re: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class'
 appear to not get parsed correctly for indentation
Date: Tue, 17 Sep 2024 20:30:58 +0000

Hello again, Arsen.

On Tue, Sep 17, 2024 at 12:43:05 +0200, Arsen Arsenović wrote:
> Hi Alan,

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

> > Thanks for taking the trouble to raise this bug report last Wednesday.

> > On Wed, Sep 11, 2024 at 20:52:15 +0200, Arsen Arsenović via CC-Mode-help wrote:
> >> Package: cc-mode

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

> >> Hi again,

> >> CC-mode appears to misindent enum and enum class:

> >>   enum asda
> >>     {
> >>       asd
> >>     };

> >>   enum class asasdas
> >>     {
> >>       asda
> >>     };

> > Yes.

> >> These should be indented same as struct per
> >> https://www.gnu.org/prep/standards/html_node/Formatting.html#index-enum-types_002c-formatting
> >> (well, enum class isn't mentioned, but I see no reason to act different,
> >> and GCC appears to do this, so it'd be convenient to keep struct-like
> >> formatting).

> > Yes.

> >> When using C-c C-s, it appears that C and C++ mode do not even recognize
> >> enum as a class-open, instead doing brace-list-open.

> > Yes.  This bug has come up at least once before, on 19 February 2014, in a
> > post to bug-cc-mode <at> gnu.org from Xue Fuqiao, Subject: CC Mode 5.32.5
> > (C/l); The indentation of `enum' of the default `gnu' style is wrong?
> > After having considered the matter for some time, I answered on 3 March
> > 2014 as follows:

> >     Even though there's a bug, it's been there for a _very_ long time
> >     (since before 1997), such a long time that it would cause chaos if
> >     it were to be fixed.  You can see many examples of this wrong enum
> >     indentation all through the Emacs C source, and probably throughout
> >     the entire GNU project.

> >     If this bug were to be fixed, inconsistent (even if correct)
> >     indentation would start creeping into thousands of files.  I think
> >     it's best left as it is, unsatisfactory though that be.

> As a data point here, the correct indentation is present all over GCC
> (which has people using everything from vi over notepad++ to VScode, and
> naturally, Emacs), but it is mixed up, presumably partially as a result
> of this bug, so I'd prefer if the editor would DTRT OOTB.

Thanks.  I've just written a little AWK script to count occurrences of
the "standard" indentation (the opening brace directly under enum in
column 0) and "non-standard" indentation (the opening brace indented
under enum in column 0).  The results have surprised me somewhat.

In "my" version of gcc-13.3.1, there are 947 standard indentations and 81
non-standard.  Even in the Emacs sources (.c, .h, .m, and .cc) we have 79
standard to 149 non-standard.  That's ~35% of enums looking like they've
been indented by private CC Mode styles, or by hand.

So my reservations from ten years ago about possible chaos were
misplaced; this chaos has already happened.

As an additional factor, the newish modes, c-ts-mode, c++-ts-mode, etc.,
indent in the standard fashion.  Also, these modes are hardly the cause
of the standard indentation in the Emacs sources, many of which date back
many years.

So it now seems clear that the decision not to fix the bug in 2014 was a
mistake.  I agree with you, it should be fixed now.

> Also, if there is intention to use automatic code formatting tools,
> which some have expressed as desirable for the toolchain projects (and I
> don't disagree - helps people who aren't using Emacs to get indent right
> easily ;-) ), having incorrect indentation by the editor will be
> burdensome, as it'd result in the editor and formatter fighting often.

> And, given that nobody (AFAIK) uses Emacs to mass-reindent code, I
> suspect the fallout of a fix will be gradual and silent.

> As an alternative to fixing this bug so that the token is recognized as
> a struct, we could have a new token for enum that does get indented
> correctly OOTB and that affected projects adjust to avoid trouble in
> their codebases.

That is one possibility, yes.  It seems clear that parsing enum
constructs as brace-lists is suboptimal, but I feel that parsing them as
structs, although easy, would be taking things just too far.  So I think
new symbols enum-open, etc., are the best way to go, even though this is
quite a lot of work (e.g. amending the CC Mode manual, the test suite,
....).

So, I will fix this bug.

[ .... ]

> No problem - thanks for responding :-)

> Have a lovely day.
> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Arsen Arsenović <arsen <at> aarsen.me>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 73182 <at> debbugs.gnu.org
Subject: Re: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class'
 appear to not get parsed correctly for indentation
Date: Wed, 18 Sep 2024 18:59:45 +0200

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

Hi Alan,

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

> Hello again, Arsen.
>
>> As a data point here, the correct indentation is present all over GCC
>> (which has people using everything from vi over notepad++ to VScode, and
>> naturally, Emacs), but it is mixed up, presumably partially as a result
>> of this bug, so I'd prefer if the editor would DTRT OOTB.
>
> Thanks.  I've just written a little AWK script to count occurrences of
> the "standard" indentation (the opening brace directly under enum in
> column 0) and "non-standard" indentation (the opening brace indented
> under enum in column 0).  The results have surprised me somewhat.

Ah!  Great idea.  Thanks for collecting empirical data.  :-)

> In "my" version of gcc-13.3.1, there are 947 standard indentations and
> 81 non-standard.  Even in the Emacs sources (.c, .h, .m, and .cc) we
> have 79 standard to 149 non-standard.  That's ~35% of enums looking
> like they've been indented by private CC Mode styles, or by hand.

Huh, that's interesting.  I expected more skew towards current
behaviour.

> So my reservations from ten years ago about possible chaos were
> misplaced; this chaos has already happened.
>
> As an additional factor, the newish modes, c-ts-mode, c++-ts-mode,
> etc., indent in the standard fashion.  Also, these modes are hardly
> the cause of the standard indentation in the Emacs sources, many of
> which date back many years.
>
> So it now seems clear that the decision not to fix the bug in 2014 was
> a mistake.  I agree with you, it should be fixed now.
> 
>> Also, if there is intention to use automatic code formatting tools,
>> which some have expressed as desirable for the toolchain projects (and I
>> don't disagree - helps people who aren't using Emacs to get indent right
>> easily ;-) ), having incorrect indentation by the editor will be
>> burdensome, as it'd result in the editor and formatter fighting often.
>
>> And, given that nobody (AFAIK) uses Emacs to mass-reindent code, I
>> suspect the fallout of a fix will be gradual and silent.
>
>> As an alternative to fixing this bug so that the token is recognized as
>> a struct, we could have a new token for enum that does get indented
>> correctly OOTB and that affected projects adjust to avoid trouble in
>> their codebases.
>
> That is one possibility, yes.  It seems clear that parsing enum
> constructs as brace-lists is suboptimal, but I feel that parsing them as
> structs, although easy, would be taking things just too far.  So I think
> new symbols enum-open, etc., are the best way to go, even though this is
> quite a lot of work (e.g. amending the CC Mode manual, the test suite,
> ....).
>
> So, I will fix this bug.

Thank you again!

Have a lovely day.
-- 
Arsen Arsenović

[signature.asc (application/pgp-signature, inline)]

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

From: Alan Mackenzie <acm <at> muc.de>
To: Arsen Arsenović <arsen <at> aarsen.me>
Cc: acm <at> muc.de, 73182 <at> debbugs.gnu.org
Subject: Re: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class'
 appear to not get parsed correctly for indentation
Date: Mon, 23 Sep 2024 21:31:02 +0000

Hello, Arsen.

On Wed, Sep 18, 2024 at 18:59:45 +0200, Arsen Arsenović wrote:
> Hi Alan,

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

[ .... ]

> > Thanks.  I've just written a little AWK script to count occurrences of
> > the "standard" indentation (the opening brace directly under enum in
> > column 0) and "non-standard" indentation (the opening brace indented
> > under enum in column 0).  The results have surprised me somewhat.

> Ah!  Great idea.  Thanks for collecting empirical data.  :-)

> > In "my" version of gcc-13.3.1, there are 947 standard indentations and
> > 81 non-standard.  Even in the Emacs sources (.c, .h, .m, and .cc) we
> > have 79 standard to 149 non-standard.  That's ~35% of enums looking
> > like they've been indented by private CC Mode styles, or by hand.

> Huh, that's interesting.  I expected more skew towards current
> behaviour.

So did I.

> > So my reservations from ten years ago about possible chaos were
> > misplaced; this chaos has already happened.

[ .... ]

> >> As an alternative to fixing this bug so that the token is recognized as
> >> a struct, we could have a new token for enum that does get indented
> >> correctly OOTB and that affected projects adjust to avoid trouble in
> >> their codebases.

> > That is one possibility, yes.  It seems clear that parsing enum
> > constructs as brace-lists is suboptimal, but I feel that parsing them as
> > structs, although easy, would be taking things just too far.  So I think
> > new symbols enum-open, etc., are the best way to go, even though this is
> > quite a lot of work (e.g. amending the CC Mode manual, the test suite,
> > ....).

> > So, I will fix this bug.

I have implemented the above, with new sytactic symbols enum-open,
enum-close, enum-intro, and enum-entry.  I have also enhanced the manual
and the test suite accordingly.  The patch is currently ~1250 lines long.

In the next day or two I will remove all my change annotations, and write
a commit message.  It should be completed and committed soon.

> Thank you again!

> Have a lovely day.
> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Arsen Arsenović <arsen <at> aarsen.me>
Cc: acm <at> muc.de, 73182 <at> debbugs.gnu.org
Subject: Re: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class'
 appear to not get parsed correctly for indentation
Date: Tue, 24 Sep 2024 21:06:32 +0000

Hello, Arsen.

On Mon, Sep 23, 2024 at 21:31:02 +0000, Alan Mackenzie wrote:
> On Wed, Sep 18, 2024 at 18:59:45 +0200, Arsen Arsenović wrote:

[ .... ]

> I have implemented the above, with new sytactic symbols enum-open,
> enum-close, enum-intro, and enum-entry.  I have also enhanced the manual
> and the test suite accordingly.  The patch is currently ~1250 lines long.

> In the next day or two I will remove all my change annotations, and write
> a commit message.  It should be completed and committed soon.

Now done.  The new scheme is now in the master branch.

Before I close the bug, could you give the code a quick testing, please,
just to be as sure as possible that the change is correct.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Arsen Arsenović <arsen <at> aarsen.me>
Cc: acm <at> muc.de, 73182-done <at> debbugs.gnu.org
Subject: Re: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class'
 appear to not get parsed correctly for indentation
Date: Wed, 25 Sep 2024 20:56:33 +0000

Hello, Arsen.

On Wed, Sep 25, 2024 at 22:42:58 +0200, Arsen Arsenović wrote:
> Hi Alan,

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

> > Hello, Arsen.

> > On Mon, Sep 23, 2024 at 21:31:02 +0000, Alan Mackenzie wrote:
> >> On Wed, Sep 18, 2024 at 18:59:45 +0200, Arsen Arsenović wrote:

> > [ .... ]

> >> I have implemented the above, with new sytactic symbols enum-open,
> >> enum-close, enum-intro, and enum-entry.  I have also enhanced the manual
> >> and the test suite accordingly.  The patch is currently ~1250 lines long.

> >> In the next day or two I will remove all my change annotations, and write
> >> a commit message.  It should be completed and committed soon.

> > Now done.  The new scheme is now in the master branch.

> > Before I close the bug, could you give the code a quick testing, please,
> > just to be as sure as possible that the change is correct.  Thanks!

> Yes, this now looks correct.

Many thanks!  I'm now closing the bug with this post.

> Thank you again!

> Have a lovely day.
> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Arsen Arsenović <arsen <at> aarsen.me>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 73182 <at> debbugs.gnu.org
Subject: Re: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class'
 appear to not get parsed correctly for indentation
Date: Wed, 25 Sep 2024 22:42:58 +0200

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

Hi Alan,

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

> Hello, Arsen.
>
> On Mon, Sep 23, 2024 at 21:31:02 +0000, Alan Mackenzie wrote:
>> On Wed, Sep 18, 2024 at 18:59:45 +0200, Arsen Arsenović wrote:
>
> [ .... ]
>
>> I have implemented the above, with new sytactic symbols enum-open,
>> enum-close, enum-intro, and enum-entry.  I have also enhanced the manual
>> and the test suite accordingly.  The patch is currently ~1250 lines long.
>
>> In the next day or two I will remove all my change annotations, and write
>> a commit message.  It should be completed and committed soon.
>
> Now done.  The new scheme is now in the master branch.
>
> Before I close the bug, could you give the code a quick testing, please,
> just to be as sure as possible that the change is correct.  Thanks!

Yes, this now looks correct.

Thank you again!

Have a lovely day.
-- 
Arsen Arsenović

[signature.asc (application/pgp-signature, inline)]

Previous Next

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