Posted Monday, 28 June 2010
After nearly five years of first using it, I've gone back to using good old mutt. I've tried everything and come to a single conclusion: mutt is the most no-nonsense featureless (and suckless) email client. Even with so many new clients, nothing beats it in 2010. With TokyoCabinet caching, IMAP is blazing fast and GMail just works out-of-the-box. With gdata API + caching, anybody can whip up a quick Python/ Ruby script to fetch the Google Contacts. It took me four years because I've only started feeling the pain now- I've been handling large volumes of email over the last few months, especially patches and patch reviews. Now that I'm an active contributor to git.git, email is the one thing that I cannot live without. To put it tersely, mutt is a compromise- it does certain things really well and is completely incapable of handling the rest: it's completely featureless. I'd certainly not recommend it to anyone who writes less than 20~30 large emails everyday. Here's what I realized: at this volume, I don't need fancy features like cute colored labels, filters, high speed full-text search, and easy-to-grasp UI as much as the other basic features. Yes, the closest competitor is the GMail web interface.
What the web interface gets right: keyboard shortcuts, filters, labels, threading and humanized date display are awesome. It's awesome when email newbies are simply top-posting and adding to an ongoing conversation casually. On the Linux kernel and Git mailing lists, people are actually quoting individual chunks, and respecting the In-Reply-To header. GMail simply collapses everything into a linear thread the way it "feels like" (depending on In-Reply-To, subject etc); it also randomly collapses quote blocks with no apparent consistency. Not to mention how it damanges whitespace, making it unusable for sending or even downloading patches from. Another major problem is the lack of configurability: any hacker will automatically find out his/ her point of inefficiency during work and invest time to write a program to (partially) automate the repetitive task.
Other desktop email clients are worse. GMail has made sure that nothing comes close by exposing labels as separate folders over IMAP: hence, if your email client had to pull labels from GMail, it must first discover all the IMAP directories and download mail headers from them; then it must run a filter to find mails matching the Message-Id in "All Mail" and label them appropriately. Huge PITA. Archiving actually means copying the email from INBOX to "All Mail", and deleting the copy in INBOX. Filters are just inaccessible. Also, no (other) email client seems to implement IMAP in a sane manner: opening up "All Mail" is like asking for trouble (I never delete a single email, and often search through my archives). They also seem to have forgotten to implement the killer feature in GMail: search. It seems to be the problem with a lot of end-user GUI software in general: the engineers focus so much on which button to put where that they completely forget to implement basic features like sending emails without damaging whitespace.
Sup came close with its full-text search, but it's not without its share of problems- users were relying on a hopeless piece of software called offlineimap to mirror their complete GMail accounts locally. Sup had some "cute" features, but it takes years to engineer and build something as solid as mutt. I don't trust infrastructure in the Ruby world.
So what does mutt do? It does IMAP and threading exceptionally well, I can use an editor of my choice, and it's supremely configurable. It's what an email client should ideally be. Yes, I'm annoyed that it's featureless, but that's a trade-off that I have to make. I configured it heavily to behave like a combination of GMail and Emacs, and I'm quite happy with it. It's not without its share of annoyances however:
- You can't have conditionals in the muttrc. That means no humanized relative dates, no choosing an editor depending on the situation. The workaround is to use a script to generate the muttrc everytime you start mutt.
- The full-text search is obviously slow if you don't have the message bodies in the cache.
- The default keybindings are not suitable for GMail users who often need to flip between IMAP folders. A LOT of painful configuration is required: even with macros, things like send-and-archive-conversation can be pretty challenging to get right. Even things like the default date display is useless: it just says that all the 100 emails in my INBOX were received today; how useful is that? In short, it needs to be customized heavily before first use.
- No out-of-the-box support for muting conversations. You'll need some sort of folder hook.
- No reading and composing at the same time. When I hit compose, mutt fires off Emacs to edit, and just hangs there waiting for Emacs to finish. For sup, writing the feature took just a few hours, but it'll probably be much harder to get right in C. The workaround I've devised is to compose emails at my leisure and then just paste it into the buffer when mutt pops it up.
- Last but not least, mutt can't fill in missing parts of the conversation from "All Mail" to produce GMail-like threading for messages in my INBOX. This is probably very hard to get right- I don't know of any email client that does it.
I'm sick of hearing myself say it- the world really needs an email client that wasn't created in 1995. Maybe I'll do something about it one weekend, but I'm too busy to get into this at the moment. Until then, mutt it is; web interface for full-text search.