Feature request: Replicate (paleo-)mutt's reactions to Maildir entries changing underneath neomutt

[kinnison]

What would you like to be able to do?

Context:

I have multiple computers, all of which talk to my email via a combination of mbsync or offlineimap synchronising my email to a local set of Maildirs. Currently some of these systems use neomutt and some use (paleo-)mutt.

In all cases I use searching tools such as mairix or mu to index my emails and let me create virtual folders with the results of searches. I have this set up to operate in a single maildir, so if I run a search, the old search results are removed by the tool and replaced by the new ones.

In addition, I commonly have more than one machine running at once, and as such mails showing up in my mailbox may be processed and deleted on one computer, before I move to another computer in order to do something else which may involve emails.

What happens

When an email is deleted from another computer, (paleo-)mutt removes the entry from the index as soon as I navigate the message list in any way (e.g. pressing up or down). Neomutt in contrast simply marks the removed item with a D as soon as it notices the file has been removed from the Maildir underneath it.

From the normal mailboxes perspective this means that if I have processed and removed a lot of email on one box, and then come to a neomutt computer, my mailbox is often filled with messages I thought I'd already dealt with, simply marked D which was exceedingly jarring when I first saw it. I was worried that my new mbsync setup was behaving incorrectly.

From the search tool perspective this is even worse. Both tools I use recommend a {neo,paleo}mutt macro which switches to the virtual folder first in a read-only view, and then runs the search since that's the easiest way to leave the search tool in the command line for editing. Thus the MUA opens the virtual folder, and the index shows the old search results (this is fine). Then I run the search, and the index updates with the new search results (also good), however here the difference in behaviour occurs once more. The old mutt simply removes the old search results from the index. Neomutt marks them all with D which leaves a mess in the index. Switching away from and back to the virtual folder clears those, as does unmarking read-only (%), syncing the mailbox ($), and then re-marking read-only. However both of those "solutions" are very very awkward.

What needs to change in NeoMutt?

Ideally, if an email is removed underneath neomutt from a Maildir, rather than marking it D in the index, it should simply be removed from the listing of emails. If for reasons of keeping partially altered but un-sync'd mail boxes clean this cannot be done, then it should at minimum be done for read-only mailboxes with no in-flight changes. (i.e. the second use-case above).

If the current behaviour was deliberately constructed from a user-experience perspective, then I would like there to be a configuration option to permit me to return neomutt's behaviour to that of paleomutt's for this particular thing.

Have you tried any alternative methods?

I have searched the documentation for ways to run a command and then switch folders in a macro, but that doesn't seem to be possible, and I've also searched for settings which might relate to this change in behaviour vs. the old mutt way, but I cannot find anything there either.

Reproduction method

Have a neomutt set up to read Maildirs.

1. In a terminal, mkdir -p /tmp/box/{cur,new,tmp} and acquire a suitable email file to test with.
2. Cause neomutt to open /tmp/box (if simulating the second use-case, mark this read-only now)
3. Create or copy an email into /tmp/box/tmp and once you're ready, mv it into /tmp/box/new if simulating the first use-case, or /tmp/box/cur to simulate the second use-case
4. Note how neomutt shows the email. This is good
5. Now delete the file from /tmp/box/new or /tmp/box/cur depending on what you did in 3.
6. Note how neomutt marks the email with a D flag. This is sad.
7. Note how you cannot open this present-but-marked-for-deletion email (since of course the backing file is no longer present). This is awkward UX
8. Note how, if you marked the mailbox read only to simulate the second use-case, you now cannot do anything about this spurious "search result" since you cannot hit $ to sync the mailbox as it is read-only.

[aspiers]

I guess "(paleo-)mutt" refers to the original mutt?

[kinnison]

I guess "(paleo-)mutt" refers to the original mutt?

Yes, when I wrote up this feature request I was switching from mutt(-patched) in Debian to Neomutt in nixos and encountered this very awkward situation. It is still something which is painful for me to this day; unfortunately my C knowledge has atrophied to the point that I was unable to produce a patch myself when I tried :(