Re: [PATCH] Add checks for new and tmp directories to mx_is_maildir()

Milan Straka <[email protected]> Mon, 9 Feb 2026 19:38:08 +0100
Newsgroups	gmane.mail.mutt.devel
Message-ID	<aYopkMOgsb6C4hbo@tensor>
> -----Original message-----
> From: Rene Kita <[email protected]>
> Sent: 9 Feb 2026, 18:20
>
> On Mon, Feb 09, 2026 at 10:07:11AM +0100, Fabian Groffen via Mutt-dev wrote:
> > On 09-02-2026 00:51:00 +0100, Gero Treuner wrote:
> > [...]
> > > I generalized the patch to cover subpaths of different lengths and also
> > > applied the optimization to mx_is_mh() .
> > > 
> > > IMO code clarity is sufficient. The array declarations could be moved
> > > inside the function, if that might further improve it. Repeated function
> > > calls are avoided, CPU cycles probably similar, and size of binary
> > > slightly reduced: ~100 Bytes for stripped mh.o and also affecting the
> > > final binary (not stripped) on my Debian Linux amd64 machine. But I
> > > assume that with different compilers, optimization flags and machines
> > > results vary.
> > > I decided against the proposed fstatat(), because most likely there are
> > > some mutt users on machines not supporting it. Adding detection and
> > > alternative code should be overengineering.
> > > 
> > > The code is custom-made to fit to the current buffer code. (Extending it
> > > would not be an option in an exercise to minimize code.)
> > 
> > I like this a lot.  It's clear and easily extendable.
> 
> Me not. And as Kevin already committed his version to the master branch,
> I don't see much value in discussing this any further.

Personally (and I do not impose the view on anyone) I find the patch to
be of negative value. I has zero practical effects and introduces two
specialized macros to modify a code that was perfectly readable before
into a form I do not find better. Plus in my eyes it has some
"maintainer energy cost"; when I put my maintainer hat from other
projects, I would have to decide whether to accept the code I do not
particularly like or write a polite reason why not to, and this would
require some amount of energy (maybe up to the point of doing something
else instead of handling the situation).

So I would like to say out loud, Kevin or other maintainers, that I find
it perfectly fine not to accept the patch and even not to react to it in
case you would feel similar (but I do not mind if you choose any other
solution).

Cheers,
Milan S.
signature.asc (application/pgp-signature, 833 B)