clang-format

"Kevin J. McCarthy" <[email protected]> Sat, 14 Mar 2026 18:47:18 +0800
Newsgroups	gmane.mail.mutt.devel
Message-ID	<abU8tgKV8GVm4fIz@qinghai>
Yes, I know... I know... I said I had no intention of doing any kind of 
formatting.  But this weekend I started looking at clang-format and put 
together a config file "roughly" similar to the existing codebase.  I 
haven't decided for sure I want to do this, but I was hoping to get some 
feedback and discussion.

But first: I beg, please restrain yourself from turning this into a 
"let's redesign the Mutt format standards from scratch" discussion.  I'm 
looking for targeted discussion on the merits or potential issues with 
these settings and how they can reflect the general current "standards", 
such as there are.

If you try it out, note that there are two files that shouldn't be 
entirely reformatted.  In init.h, the config options array is carefully 
formatted to be read by the documentation generator, so that whole long 
list shouldn't be touched.  The same in functions.h with the various 
maps.

Also, reformatting in a few instances separates L10N comments from the 
marked parameter.  I've noted the places that need to be cleaned up 
after my trial.  If we go ahead I'll do that again.

My laptop is running Arch, which has clang-format version 21.1.8.  It 
seems there is some churn on the options and what appropriate values are 
available across versions.  For instance, SpaceInEmptyBraces seems to be 
available starting at 22.

Now, after that overlong intro... here are some points in the config I 
want to emphasize for potential discussion (or limit discussion on):

>ColumnLimit: 80
>PenaltyExcessCharacter: 5

The intent here is to have a standard 80 column limit but not to be 
draconian about it.  The formatter is free to go longer, if it helps 
with other formatting trade-offs.  I don't know much about penalties.  If 
you have experience and think "5" is too low or too high, please let me 
know.  Or if there is a better way to set a limit that is flexible.

>IndentWidth: 2

This has been the standard in the Mutt code for a long time, and I'm not 
flexible on this one.

>SpaceAfterCStyleCast: true

I think this is generally the case in the mutt code but it's not 
uniform.  I don't insist on this one.  Definitely open for discussion.

>IndentGotoLabels: false

There are both styles in the code.  Also definitely open for discussion.

>KeepEmptyLines:
>  AtEndOfFile: false
>  AtStartOfBlock: false
>  AtStartOfFile: false

It seems like a good idea?  Please say something if in your experience 
this isn't.

>AlignAfterOpenBracket: Align

This is generally the case in the Mutt code.  I think overall it looks 
nice, but there is the trade-off with long function names and/or deep 
indention where parameters start to not all fit within 80 columns.

>SpaceBeforeParens: Always

I know this one is controversial.  It took me a while to get used to the 
function definition and declaration style in Mutt.  It's not very 
standard, so I'd appreciate some other viewpoints, but let's not get 
bogged down on this one, okay?  I'm most likely not up for changing it 
unless I hear old-time devs chime-in against it too.

Anything else I missed or you see that's a bad idea?  Please speak up. 
Thank you.

Anyway here's the config I tried this morning:

AlignAfterOpenBracket: Align
AlignArrayOfStructures: Left
AlignConsecutiveAssignments: None
AlignConsecutiveBitFields: None
AlignConsecutiveDeclarations: None
AlignConsecutiveMacros: Consecutive
AlignEscapedNewlines: Left
AlignOperands: Align
AlignTrailingComments:
   Kind: Leave
AllowAllArgumentsOnNextLine: false
AllowAllParametersOfDeclarationOnNextLine: false
AllowShortBlocksOnASingleLine: Never
AllowShortCaseExpressionOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortEnumsOnASingleLine: false
AllowShortFunctionsOnASingleLine: None
AllowShortIfStatementsOnASingleLine: Never
AllowShortLoopsOnASingleLine: false
AlwaysBreakBeforeMultilineStrings: false
BinPackArguments: true
BinPackParameters: true
BitFieldColonSpacing: Both
BreakAdjacentStringLiterals: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Allman
BreakBeforeTernaryOperators: false
BreakBinaryOperations: Never
BreakFunctionDefinitionParameters: false
BreakStringLiterals: false
ColumnLimit: 80
DerivePointerAlignment: false
IncludeBlocks: Preserve
IndentCaseBlocks: false
IndentCaseLabels: true
IndentGotoLabels: false
IndentPPDirectives: AfterHash
IndentWidth: 2
IndentWrappedFunctionNames: false
InsertBraces: false
InsertNewlineAtEOF: true
KeepEmptyLines:
   AtEndOfFile: false
   AtStartOfBlock: false
   AtStartOfFile: false
Language: C
LineEnding: LF
MaxEmptyLinesToKeep: 1
PenaltyExcessCharacter: 5
PPIndentWidth: 1
PointerAlignment: Right
QualifierAlignment: Leave
ReflowComments: Never
RemoveEmptyLinesInUnwrappedLines: true
RemoveParentheses: Leave
RemoveSemicolon: false
SkipMacroDefinitionBody: true
SortIncludes:
   Enabled: false
SpaceAfterCStyleCast: true
SpaceAfterLogicalNot: false
SpaceAroundPointerQualifiers: Default
SpaceBeforeAssignmentOperators: true
SpaceBeforeCaseColon: false
SpaceBeforeParens: Always
SpaceBeforeSquareBrackets: false
# SpaceInEmptyBraces: true
SpacesInParens: Never
SpacesInSquareBrackets: false
TabWidth: 8
UseTab: Never

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA
signature.asc (application/pgp-signature, 833 B)