Hacker News new | comments | show | ask | jobs | submit login
A year with Notmuch mail (2016) (lwn.net)
96 points by pmoriarty 43 days ago | hide | past | web | 18 comments | favorite



I really like the premise of notmuch, using a search index as the primary storage mechanism. I just wish it integrated better with distributed email.

I currently use IMAP for my mail, and process it on three different systems: a personal laptop, a work laptop, and a phone. Workflows based on notmuch support syncing between laptops (see the mention of muchsync in the article), but don't really interoperate with standard email protocols, and I'm not willing to give up quick access to email from my phone. And beyond that, I don't really want to have to "sync" email; I'd like to just access it seamlessly.


That's the main reason I use mu, although I like notmuch as well. Their tooling is similar in a lot of ways, but for me the most important high-level difference between the two is the storage model: in mu, canonical storage is purely in the maildir, while the index is just a search index, which can be deleted and regenerated at any time with no data loss. While notmuch tends to go the other way at least in typical usage, treating the maildir as immutable and using the index for canonical storage of metadata like filing/tagging messages, and even deletion status. Imo that gives mu's storage model more interoperability (anything that correctly manipulates maildirs can be used with it), while notmuch requires more effort to use together with other not-notmuch tools, but has more flexibility (e.g. can easily do gmail-style tagging, vs. the more traditional file-into-folders model maildirs use).

I wrote a bit about this when I investigated the two a few years ago: http://www.kmjn.org/notes/unix_style_mail_tools.html


Also notmuch took a long time to support address completion based on your email index, à la Gmail. Mu had this from almost the beginning.

That said, I love both. They are excellent search engines for mutt. Those, along with mbsync make up a wonderful email setup.

I have recently transitioned to Gnus, that now supports notmuch [1]. I don't like the notmuch Emacs frontend. The mu one, mu4e, is great though.

[1] https://www.gnu.org/software/emacs/manual/html_node/gnus/The....


I wonder if you could use the mu4e front-end with a notmuch backend.


Mu4e communicates with the mu backend through an s-expression based protocol [1], so in principle any other backend that implemented the protocol could work with mu4e. Not aware of anyone having written an alternate backend though.

[1] http://manpages.ubuntu.com/manpages/precise/man1/mu-server.1...


Have you considered ssh'ing in to a remote server from your phone and running emacs (or other notmuch client) from there?


I used to ssh to my server and run mutt from my phone, back when I had a phone with a hardware keyboard. That's a lot less satisfying when half your screen area is taken up with a software keyboard in order to drive your mail client, while you're trying to read and process mail.

So no, I'm not willing to give up having a "native" client, or at least something web-based.

Honestly, notmuch would make an incredible backend for a webmail client, ideally with a mobile-first interface.


"That's a lot less satisfying when half your screen area is taken up with a software keyboard"

You could carry an external, mini-keyboard for your phone and use that. It's annoying, but, as you note, screen-keyboards are annoying as well.


When I'm using my phone to process email, I don't generally have any surface available on which I'd put a keyboard.


This is what I do often, but with gnus in emacs and mbsync. I've seen more stuff lately on not much and plan to check it out.


Found notmuch when I closed my gmail acct years ago, love it. I use a wrapper[1] that integrates it with alot[2] and an optional custom MDA[3].

[1] https://github.com/jakeogh/gpgmda-client

[2] https://github.com/pazz/alot

[3] https://github.com/jakeogh/gpgmda


"Notmuch does not index all headers; two missed headers that are of interest to me are 'X-Bogosity' and 'References'."

I wonder why Notmuch doesn't just index all headers?

It seems like it would be useful to do so, as some header might be of interest to some user out there, even if it's not to the authors of the program or to most users. So what's the downside of just indexing everything?

If it's a performance consideration, then there could just be a simple configuration file option that determines whether all headers are index or not, or maybe a user-configurable list of headers to index would work instead.


I've used notmuch with the emacs plugin as my primary email system for years. It's the best thing I've ever used and I really feel hobbled using anything else. Gmail isn't bad for a web interface, but its searching is inferior.


Same here. I've tried so many other clients. Mutt(which is obscenely overrated and shitty), mu4e, various GUI clients like Thunderbird, etc, etc.

The only thing that really works is notmuch. It's so much easier to just lump all your mail together, and then tag it appropriately based on the content or whatever.


Speaking of hacker-friendly email clients. Snackis offers editable threads, full-text search and encryption in a single, convenient package with a GTK GUI on top.

https://github.com/andreas-gone-wild/snackis


I understand that tastes are different, but... Red text on black background? I couldn't even read the github readme.


I like it that way, looks better than in the pictures if you ask me. It is, however completely CSS-themeable; the theme you saw in the README is included as an example. If someone else is willing to put their time into an alternative theme, I'd be happy to include it. To summarize; if that's your only issue I suggest another look.


Office 365 and Outlook solves my email problem perfectly - their "focused inbox" emphasises important mail while leaving the cruft behind and the spam filter is excellent.

For those with thousands of emails every day maybe the solution is to receive less mail instead of finding tools to manage it.




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: