jmtd → log → mutt year zero

For better or worse I'm a heavy email user, not least because so much of the traditional workflows in Debian are email based. I use a variety of email clients but my swiss-army knife is mutt, and has been since at least 2005, which is the earliest-dated comment in my mutt configuration files.

I've always used the mutt package as provided by Debian, which means in practice I have been actually been using neomutt since around 2016, when the Debian maintainers imported that patch-set into the mutt package. neomutt is an independent effort to coordinate development of mutt (or on top of mutt) as the upstream maintainer(s) were (for a time) largely dormant. It's meant to be a friendly project, in some cases incubating patches that people are still trying to submit to the upstream project.

Fast forward to 2017 and an upstream mutt maintainer complained that Debian is providing something called "mutt" that is actually "neomutt" and started making pseudo-legal threats. This could have been resolved in a number of ways (my proposal and plea are recorded in that bug), but the decision of the package maintainers was to switch the mutt package back to the mutt source and provide neomutt as a separate Debian package.

We now have a situation where

• If you were using mutt in Debian from 2016 onwards, you were most likely using neomutt, and your configuration files are most likely tailored to neomutt. If/When you upgrade to the next stable Debian release, you will be moved to real-mutt and your configuration may break.

• if you filed a bug against the mutt package, depending when you did and what version of Debian you were using, your bug might be assigned to the mutt source package, which is now real-mutt, but might actually relevant only to neomutt. Looking merely at the list of bugs against "mutt" is not enough to be sure it's a bug in mutt, or neomutt, or both.

• real-mutt and neomutt have not yet co-existed in a Debian release, so you cannot evaluate both side-by-side without introducing packages from testing or unstable, which might mean a libc upgrade.

• Lots of stuff, especially Debian devscripts, hard-code /usr/bin/mutt as a mailer. The neomutt package does not provide this binary, and it is not mediated by the alternatives system, so if you only install neomutt, you might have integration niggles to solve yourself.

For a short while, I attempted to adjust my configuration files so that they would work in both real-mutt and neomutt, but this proved too messy so I've given up. I did have them co-installed on my main mail-reading host, but I also found myself occasionally confused as to which I was actually running at a given moment, so I've decided to stick to neomutt everywhere going forward: which means neomutt on my main mail host, and the mutt package on my Debian-stable hosts, and I must remember to switch the packages over when I update them to Buster (the next stable release) in a month or two.

The other upshot of this is I've decided to declare "year zero" on my mutt configuration files, rather than try to adapt the mess of mixed mutt and neomutt configuration bits spread across a dozen files that have grown since (at least) 2005, I'm going to start from scratch and only import over something if I feel its absence in daily use.