Hacker News Reader

The problem is we don't have the users from 20-30 years ago either.

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.

I wish I could reject messages where the subject and body did not correspond.

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

Exactly. Gnus is a marvelous client because it has really good NNTP and threading support (silencing and automatic scoring) that allows you to cope with gigantic volumes of email.

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.

Have you tried mu4e?

I have spent a decade running mutt, a year running Gnus and a few months running mu4e before switching to notmuch on Emacs.

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.

Notmuch has potential, but also a bunch of limitations and issues compared to Gnus.

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.

I ran Gnus with notmuch backend (nnir-notmuch) for many months. It's not very fast as Gnus is not very quick on Maildirs.

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.

Autocompletion from the notmuch database is fine when you don't have many addresses in there. But when you are subscribed to a bunch of large mailing lists and you try to search your notmuch database for "John" you're going to get a thousand completion candidates.

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.

Sure, all these points are true. Notmuch is a bit unfinished I think. What email setup do you have?

I'm actually using notmuch in emacs myself, but I'm just running in to a bunch of its limitations and looking around for an alternative.

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

Maybe give Gnus a try anyway. It might not be that slow on good hardware. Or just run it coupled with a Dovecot server.

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.

> This is one of the things that web-based forums have yet to get right. Email (and NNTP news) clients from 20 or 30 years ago are far superior in this respect, because they can intelligently deal with threading and folding.

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.

Can we do that with a chat system? Because Slack threading is just inadequate, imo.

I'm trying to solve this right now with eul[0]. It's not an easy task.

[0]: https://eul.im

Looking forward to OTR for XMPP :)

HN-NNTP gate, anyone?