Re: clang-format

"Kevin J. McCarthy" <[email protected]> Thu, 19 Mar 2026 11:05:53 +0800
Newsgroups	gmane.mail.mutt.devel
Message-ID	<abtoES9-_XG9ro3U@qinghai>
On Wed, Mar 18, 2026 at 11:21:28AM +0800, Kevin J. McCarthy wrote:
>Okay, you don't have to twist my arm.  I resisted formatters myself 
>for a long time already, but started to feel like "everyone else was 
>doing it" and thought I'd give it a look.
>
>Before I drop the proposal, though, are there any Mutt 
>devs/contributors who would like to play devil's advocate?

Thanks Robin (yes your voice counts too), Will, Steffen, and of course 
Alex for continuing the discussion some more.  I was getting mostly 
negative feedback and wanted to know if *anyone* felt there was a 
benefit to formatters.

Just looking over the initial results of my trial run last weekend 
again, there are some iffy results, but overall it wasn't that terrible. 
I suppose how you feel about the result depends on how picky you are 
about formatting, and how well your format style can be expressed in the 
.clang-format config.

The mutt code is already on the messy side.  It's a mostly-Allman style 
with a space in front of funcalls.  But otherwise is a mish-mash of 
pointer-operator locations, cast styles, and other miscellanea.  I think 
a little iffy results would be okay if it meant smoothing out the 
inconsistencies.

My only problem is the gettext calls are spaced too: "_ (" and "N_ (". 
I was initially thinking about following up with a sed script to fix 
those.  But now, I'm actually leaning towards getting rid of the space 
before parens completely.  It's not a conventional style, and combined 
with nested gettext calls (or any nesting really), looks terrible.

This weekend, I'm planning on releasing 2.3.1 from stable.  After that, 
I think I'll change the config to remove the space before funcall, run 
it again, commit to a branch and announce it here.  You all can take a 
look and tell me what you think.

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