--- Begin Message ---
|
Subject: |
CC Mode 5.35.2 (C++//l); C++ concept indentation |
|
Date: |
Wed, 22 Mar 2023 11:58:32 -0400 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Package: cc-mode
Given a concept definition like:
template <typename T>
concept Foo =
Bar<T>
&& requires (T t) {
{ t + t } -> std::same_as<T>;
}
&& something_else;
This is how it actually indents in cc-mode:
template <typename T>
concept Foo =
Bar<T>
&& requires (T t) {
{ t + t } -> std::same_as<T>;
}
&& something_else;
I would expect "Bar<T>" to be statement-cont, but it is
topmost-intro-cont instead. The indentation of "{ t + t }" isn't offset
properly with respect to the "requires" clause, and the closing brace is
way out of line.
I suspect that this is merely because concepts haven't really been
handled specially outside of recognizing the keyword. Changing the
"concept" keyword to "int" improves the indentation of "Bar<T>",
demonstrating what I think the indentation should be, and replacing the
"requires" with "[]", making it into lambda syntax, also improves the
indentation. I think that requires expression should be indented in a
similar manner as lambda expressions are indented.
Thank you!
Emacs : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0)
of 2023-03-12
Package: CC Mode 5.35.2 (C++//l)
Buffer Style: Pharos
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
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 '((brace-list-open) (brace-entry-open)
(statement-cont) (substatement-open after)
(block-close . c-snug-do-while)
(extern-lang-open after) (namespace-open after)
(module-open after) (composition-open after)
(inexpr-class-open after)
(inexpr-class-close before) (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 nil
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 . 0)
(inextern-lang . 0)
(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 . *)
(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 . c-lineup-topmost-intro-cont)
(brace-list-intro . +)
(brace-list-open . 0)
(inline-open . 0)
(arglist-close . +)
(arglist-intro . +)
(statement-cont . c-lineup-math)
(statement-case-open . *)
(label . *)
(substatement-label . 2)
(substatement-open . 0)
(knr-argdecl-intro . +)
(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 "[ ]*\\(//+\\|\\**\\)[ ]*\\([
]*\\([-–!|#%;>*·•‣⁃◦]+[ ]*\\)*\\)"
)
--
Michael Welsh Duggan
(md5i@md5i.com)
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#62386: CC Mode 5.35.2 (C++//l); C++ concept indentation |
|
Date: |
Fri, 14 Apr 2023 17:01:13 +0000 |
Hello, Michael.
On Fri, Apr 14, 2023 at 08:03:40 -0400, Michael Welsh Duggan wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > This is a difficult one. Aligning the || under OctetLike causes problems
> > when the parenthesis is already far to the right, for example if requires
> > is on the same line as template. Then everything will be indented too
> > far to the right. This dilemma has come up at least twice before.
> > I think what's worse is the lack of further indentation of the && line.
> > I don't know what to do about that, at the moment.
> I guess I just see it as the standard parenthesized expression problem
> that already exists. It's generally up to the programmer to make sure
> opening parentheses don't happen too far to the right.
> I agree about the && line.
> > I'm also a little bit worried about the "virtual semicolon" detection on
> > some more complicated requires constructs.
> > Anyhow, I think I'll commit what I've got, and leave these doubts to be
> > cleared up later.
> Sure. I'm generally happy with the improvements that have been made so
> far.
OK, I've committed the patch, and I'm closing the bug, even though the
patch is imperfect.
> --
> Michael Welsh Duggan
> (md5i@md5i.com)
--
Alan Mackenzie (Nuremberg, Germany).
--- End Message ---