Now, even though I and my email client still use threading, much of my incoming corpus does not. Instead, I see a mixture of users who break every thread (no In-Reply-To headers, ever), users who cannot comprehend subject metadata versus first line of message, and users who use the most recent few screens of activity as an address book, always replying to the end of a thread with a completely unrelated and new topic.

Or maybe give up and have some sort of manual threading overlay where I could rearrange and add my subject tags for messages..

It's a bit sad the code is messy and it's a tad slow compared to other options.

Notmuch for Emacs has so much potential to replace Gnus. The interface is incredibly fast and friendly (a classic tree view and a threaded view that IMHO surpasses Gmail). Plus super quick search.

I think it could become a killer application for Emacs (the other two now are org-mode and Magit IMHO).

However, there's no good tooling to keep Notmuch in two-way sync with maildirs right now. Everything works based on tags, which is incredibly flexible, but there should be some tooling to implement logic that allows moving mails around based on their tags, so that the remote IMAP store gets tidy.

People usually rely on scripts for simple use cases, which is fine albeit a bit hacky. Some DSL that resembles Sieve, but implemented in ELisp would be cool.

Notmuch doesn't have scoring, it doesn't have BBDB integration, it has no way to get arbitrary message headers from elisp, it only indexes a handful of headers.

I've heard it is possible to use notmuch as a backend for Gnus, to get the best of both worlds.

As for two-way sync, some people have come up ways of doing that, using something like Sieve.

For me two-way sync is not super critical, as I've come to view the webmail interface of my mail provider as just a backup to use in case my laptop dies or something. In all other cases, I'll just use notmuch, for which local tags are enough.

Scoring could be quite easy to implement with auto-tagging. Tags are a unifying concept in email. You can implement any custom user logic with tags. What notmuch is missing is a bit of tooling to do this. It'd be cool if this tooling had access to any arbitrary header, as you have pointed out.

I feel I don't need BBDB integration when I have autocompletion based on the email database. That said, there's bbdb-notmuch.el, and I assume other options as message-mode is really a Gnus thing.

I think basic two-way sync is almost always needed. Otherwise you end up with a huge inbox and even if you don't care at all about the remote IMAP store, mbsync calls will start slowing down.

If instead you search just your BBDB database, which only has the contacts you actually correspond with, you're going to get just the useful and relevant ones... and you'll always have the notmuch database to search on as a backup, in case the contact you want to to correspond with is not in BBDB yet.

Very sorry to hear that Gnus with a notmuch backend is slow, as that's what I was considering trying next.

I really like Notmuch's interface. I think limitations are perhaps not that hard to patch on Elisp unless you have a complicated setup.

I'm trying to implement a DSL to coordinate tag <-> maildir sync on top of a few macros.

Mu4e is fine, but I found the interface slightly slow and awkward compared to notmuch. Notmuch's interface is really really good and quick.

Mu4e doesn't ignore underlying folders, which is cool if you have a very simple workflow. It's also superior to notmuch in the sense tags are stored in message headers, so they can easily be sync'ed across clients.

If you buy Reddit gold which makes Reddit to highlight posts that are new since you last time viewed the discussion, then Reddit becomes almost as good as NNTP clients were 20 years ago.

[0]: https://eul.im