Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thank you Mutt (and also NeoMutt for pushing the envelope), you have been my e-mail client now for the last four years and as an academic that spends a significant amount of time reading and responding to e-mail it is (somehow?) the best option out there.

Setup:

* Mutt (I had slowdowns with NeoMutt)

* Vim with four e-mail specific lines in the `vimrc`

* fdm for retrieval and delivery rules

* Syncthing for synchronisation between machines (it is just files! although ~1,000,000 of them…)

* tmux to give me a single horizontal split so that I can browse and compose at the same time

* Notmuch for search

* Lynx to beat text/html into shape

* a tiny snooze shell script of my own coupled with an equally tiny unsnooze shell script that runs every few minutes on a box that is on 24/7

That is it, although I have to admit that I should clean up my `muttrc` at this point as it is an outright mess. There are always more tweaks one could perform, my next one probably being figuring out tagging and then sending multiple mails to the snooze script. But one has to exercise a bit of self restraint or get less rather than more work done due to “over tweaking”.

Gripes? Well, the configuration is very arcane at times and monolithic; you wish you had a more modern, scriptable, and modular interface. If so, you could probably cut down the time it takes to get something working by more than half. I also suffer occasional CPU spikes, perhaps due to some weird interaction with Syncthing when both monitor directories.

Other than that, it is very smooth and pleasant sailing. HTML e-mails in particular hardly if ever pose a challenge after I got Lynx into the mix.



> the configuration is very arcane at times and monolithic;

For my needs it seems quite modular. I have one ~/.mutt directory with separate muttrc files for every email account (10+) and within each account I use folder-hook to have separate (many are shared) config files.

Arcane is more subjective, but I like it.


It does get more intuitive over time once you grasp some of the fundamentals of interactions with external programmes and how the query language and hooks are what you should first reach for. This I suppose is the “arcane” part, it can be difficult to both grasp and find good resources that teach you the ropes. However, this is fairly common for the *NIX command line and can be a strength as well in the end.

What usually gets me is how some functionality is just barely out of reach, unless I am mistaken for example there is no way to pipe the path(s) (not the message(s) themselves!) to an external programme. So for my snooze script I instead pipe the messages(s), parse them to extract the Message-ID(s), pass them to Notmuch to turn them into path(s), save to a temporary file, launch another command pointed at the temporary file, query the user for input, create a directory based on the input, and move the file(s) into the directory. It works, but it is awfully roundabout and I do at times wish I had some sort of scripting language that interacted with Mutt primitives rather than a monolithic set of functions which can only be extended by patching the source.


After many years of using mutt the lack of flexibility really started to eat away at me. I decided I'd write my own console-based mail-client with a real/complete scripting language.

The result was very flexible and customizable for myself:

https://github.com/lumail/lumail/

https://lumail.org/

Unfortunately after 10+ years of self-hosting my email on a virtual machine I've now switched to paying for GSuite, so the project has become orphaned. For a while I thought there was a chance it would become popular and useful, but I guess the userbase for these kind of applications is pretty small - almost everyone still using mutt does so because they love it, and are used to it. Changing isn't an easy thing to do.

I'll be interested to see how Aerc turns out:

https://aerc-mail.org/


Do you mind sharing how to use notmuch from mutt? Does mutt support virtual folders like neomutt?


Mutt does not support virtual folders, so there is nothing fancy really about how I use Notmuch as I only use it for search (not tagging). I have a macro to call `mutt-notmuch.py` (there is a Perl version as well) to: search, create a temporary read-only maildir based on the current TTY, and lastly populate in with symlinks to the search results – Mutt then switches into that maildir.

I would love to use Notmuch more, but syncing between devices becomes a pain when everything is no longer a file. There is muchsync [1], but I really do not want to go down the rabbit hole of resolving potential conflicts, etc.

[1]: http://www.muchsync.org/


Thanks for sharing your experience.

I'm subscribed to several mailing lists/forums and sometimes get a 3-figure number of emails per day. Since I can't (nor want to) read all of them, I score them based on the subject field (~s). Unfortunately, the scoring algorithm can't take the body into account (~b). That's why I considered notmuch for creating (virtual) mailboxes with context I'm interested in...


> tmux to give me a single horizontal split so that I can browse and compose at the same time

Do you mind sharing how you do this? Browsing plus composing has been the one thing that keeps annoying me for not being streamlined and typically I just open multiple mutts/neomutts.


if you use tmux, read up on "set background_edit" in mutt. welcome to the 21th century! :D


I will not be much help I am afraid: `mutt` for the upper and `mutt -R` for the lower.


Oh okay, so that's basically what I do manually anyway then. Thanks.


Me too, but sometimes no need to make things more complicated. It's also a feature of mutt - that I can fire several instances almost instantaneously and use them for different purposes. I have to use outlook at work, and there's nothing more frustrating than waiting for it to load up, and not being able to view and search my old emails when I am composing emails (or is it when I'm selecting contacts - I can't remember).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: