Comment by nextos | Hacker News Reader

Comment by nextos | Hacker News Reader

Parent Full thread

I share your frustrations with Notmuch as an Emacs client. But I still find it better than Gnus and Mu4e. And I have tested all 3 extensively aside from using Mutt for a decade.

I think making the Notmuch interface "pure" is a great design decision. By pure I mean that it just operates on tags, but never deletes or moves files and it doesn't even know about folders.

This gives it great flexibility. You can implement virtually any logic in a Maildir backend by remapping tags to actual files. Any arbitrarily complicated workflow, silencing, automated scoring like what Gnus offers, etc. is possible while the UI will be the same. Just tagging.

The problem is that Notmuch developers do not bundle any tools for implementing such a backend with notmuch, and third party stuff like afew [1] is lacking. It reminds me a bit about the situation with address completion. For a long time, mu offered this, while notmuch relied on hacky third party scripts.

[1] https://github.com/afewmail/afew

I still think notmuch is a great backend, but a poor client. Despite using mu4e, I still find Gnus superior in terms of pure reading efficiency (I still use Gnus regularly with gmane). Scoring and thread handling is just superior.

There's a lot to gain from adaptive scoring alone.

In fact, I also switched over mu4e after trying a search backend for Gnus, and I've been oscillating from mutt/gnus/mu4e a lot over more than a decade.

Tagging is powerful, but I find it too constrained as a single tool to manage everything.

Yes, right now Gnus is probably the best option.

But with good logic to implement tag-based rules, something like notmuch could be marvelous.

Don't give up on Gnus, it's still got plenty of life in it!

Oh, I love Gnus. Do you use Gnus? The code is a bit messy. It needs a huge refactoring. Things have accumulated some cruft since first version, released in 1987.

It's also a bit slow unless you run a local Dovecot instance, which I dislike.

Magit and Org are Emacs killer applications. I wish we could fund some developer to refactor Gnus and port some ideas from Notmuch.

I agree with all of the above! I do use it, and am working on refactoring it (very slowly). I wrote a generalized search language for it a few months ago, which relieved some of the searching pain, but it is waiting for another rather large code update to go in before it can land.

I've been looking at how to clean up and "modernize" the code over the past few weeks, and hopefully will slowly start making commits. I've got a roadmap document I might try to add to the Emacs repo.

Awesome! Maybe if you think you have good ideas you should seek some funding from the community after your code gets a bit of momentum.

What do you think about nnir-notmuch?

Aside, don't you think it'd be easier to reimplement a big chunk of Gnus based on the principles of Notmuch? That is, make everything work on tags only and delegate all tags-to-files mapping to a backend (possibly written on some expressive Elisp DSL)?

Asking for money might be a bit much! It's still Lars' package, after all, and no one has asked for money for it so far. Plus, I'd be afraid of the "you broke it, you bought it" policy – I don't want to be responsible for the whole thing! Just the servers and groups and marks bit of it. And search, I guess. I'm just planning on making incremental changes.

What you describe about reworking Gnus to be more like Notmuch wouldn't necessarily take that much work. Gnus doesn't do any searching itself, it just delegates to a search engine like Notmuch or Mairix or the built-in IMAP engine. Gnus and IMAP are very much married to the idea of groups/folders, but none of the other search engines are. They return their results regardless of group/folder, and then Gnus actually goes to the work of filtering out results that aren't in the selected group(s).

All that's needed is to make it easier for the user to launch a search of an entire server, without forcing them to select which groups to use. This would suck for IMAP searches, but work just fine with other search backends.

If Andy Cohen's work on nnselect could land, then I could finish work on the generalized search backend. That would allow you to issue a single search against different backends (say a local maildir indexed with Notmuch, and a remote IMAP server). The search would be translated for the different backends, and all the results displayed together in one group.

Sounds great to hear there's some active development going on Gnus! As a user I was a bit upset with things slowing down.

I look forward to testing all these new search improvements.

Thanks for taking the time to write this up. I tried to hack a bit on Gnus, but I admittedly found the codebase quite overwhelming compared to Mu4e or Notmuch, which are an order of magnitude simpler and thus easier.

Reply on news.ycombinator.com