In summary: in order to display HTML emails using Mutt, the author developed a system to automatically pipe them to a tool that parses plaintext multipart MIME messages and converts them to an HTML file, which gets displayed in an auto-reloading Firefox tab. The author also set up the reverse system to compose email, piping markdown to pandoc (which also gets previewed in an auto-reloading browser tab).

What is so compelling about a terminal-based email client like Mutt that makes it worthwhile to jump through the hoops to do this, rather than simply using a regular GUI client? I agree that some terminal-based tools are unequivocally far more powerful than GUI alternatives for certain tasks. For example, as a batch processing pipeline (especially when text is involved), the UNIX shell is second-to-none (e.g. “take all CSV files modified in a certain date range, whose name matches a certain regex, and extract all members of fields A-F if field Z matches a certain regex, then sort the result by field D” is an easy shell one-liner). Editors like vim and emacs make it much faster to edit text, due to their powerful editing, navigation, and search/replace features that aren't found in any other editor (e.g. single keystrokes let you replace everything within the current bracket scope, replace everything up to the next "B", or delete the next two sentences). We put up with the (massive!) shortcomings of a terminal environment because these tools are just that much more powerful.

I don't see how a terminal-based email client like Mutt is equivalently that much more powerful than its GUI brethren. And yes, I've tried it, and wasn't impressed—it basically felt like an ncurses rendering of Thunderbird, with a similar feature set sans the ability to easily view HTML email or attachments. Yes, it’s more hackable than Thunderbird, but at the end of the day its hackability doesn’t make me a more productive email user.

The killer feature that did it for me was being able to bulk manage/delete email, keep an offline copy and (hence) enable full text search when offline.

I was in a situation where I couldn't quite get a grip on all the newsletters and spam that had accumulated, so I paid for a SaaS service to sort mail, delete and highlight for unsubscribing. When I was able to get neomutt set up (with Luke Smith's mutt-wizard scripts), I found it was pretty easy to do these things with just a few button pressed. Since it's a terminal app it feels very responsive, so you get the removal of friction between thought and action that you do with vim. I've tried to do the same with outlook on my work Windows machine and it's not as smooth - I probably wouldn't have bothered if I hadn't got the usage pattern down in neomutt.

I use Gmail for a lot of my rules and filtering, but I realise that if I ever wanted to leave Gmail then many of these 'smart' features wouldn't be available in the same way. I would, however, be able to script similar rules in mutt which takes a lot of overhead out of my email/communication/personal organisation.

Also neomutt/maildir makes it easy to use your email in scripts. You can use them as triggers or as a data source - they're just available in plain text format.

So yes, a lot of advantages, probably most could be emulated in GUIs, but it does sit much more neatly with Unix/terminal ways of working.

I’ve used mutt for many years as my only email client because it’s fast, configurable, powerful, and, most important of all, not broken:

https://lwn.net/Articles/837960/

I don’t have any problem with HTML email. Mutt formats it inline using links (my current choice), and if I want to see the graphical version, I just hit `v` to open the attachment menu, hit the arrow to put the cursor on the HTML attachment, and hit RETURN to pop it open in my browser.

>In summary: in order to display HTML emails using Mutt, the author developed a system to automatically pipe them to a tool that parses plaintext multipart MIME messages and converts them to an HTML file, which gets displayed in an auto-reloading Firefox tab.

The article has nothing to do with reading HTML emails using mutt which is actually quite easy to do, as pointed out by another commenter. The article is about sending multi-part text+HTML emails in a nice way that handles attachments, inline images, etc.

Good catch! I edited my original post to reflect this.

In a Thunderbird vs. Mutt comparison I think personal preference and primary use case factors in pretty heavily.

There are people who find working primarily in a terminal (usually, multiple) better for them. Perhaps by no coincidence, I've noticed that these people tend to work in circles where HTML email is not common, so there is little gain in "going GUI" for email.

Terminal programs, by definition and necessity, have a focus on efficient and comprehensive keyboard navigation. It is a rare GUI program that maintains a similar focus on keyboard navigation. (Thunderbird might be one, I don't know)

You can ssh into a box somewhere and use terminal programs and they feel native. Remote access to GUI programs is usually a larger compromise.

I tend to feel much more "in control" of my email workflow when I can set up complex filters, which usually leads me away from IMAP and toward email on the local disk. I've found that "old school" mail programs handle this use case better than GUI ones (which are usually focused on IMAP).

So, personally, I'm either reading mail from local storage with an old-school mail reader (for very high volume, tech related, work related, stuff), or going full cloud and using webmail (for lower volume personal mail). That way I can always get to my mail from anywhere, seamlessly (be it ssh or a browser).

Can't speak for Mutt, but, honestly, I really miss old text-based email interfaces such as Pine and Elm. Navigating through older emails was much, much easier, and there was not the visual cruft that comes along with so much email today. Email is for communicating; other than image/file attachments, there's really no good reason to have it be anything other than plain text. But that's not the world we live in.

I used notmuch/mu4e/emacs for a bit with my work email when I was in a role that got tons of email. The filtering, keyboard nav and plain text meant that the interface never got in my way and processing my email was lightning fast. Gmail gets close with filters/keyboard shortcuts, but emacs was much much faster and integrated well into my org-mode flow as well.

They are fundamentally different ways of thinking about editing, so this doesn't read like an apples to apples comparison.

Vim is all about chaining small commands together to perform complex operations, like building a pipeline in UNIX. You start off learning a few basic commands, then as your vocabulary increases you can construct increasingly complex tools just by hitting a few keys. A Windows veteran hearing about head, grep and cat for the first time might think "I can do all of that in notepad, this UNIX thing is a waste of time"... then they watch a UNIX greybeard build a pipeline in seconds that automates a hour-long workflow of clicking and form filling.

There are criticisms you could make that would read as fair, "many common editing operations are more accessible in foo", "features in foo are more discoverable", "the learning curve in foo is shallower", "I don't think it's worth the time investment to become proficient in vim/emacs" (but you would be wrong!).

I spent two years with Emacs. I had it configured to my liking and so on. It wasn't worth the time investment.

You analogy with head, grep etc. falls apart because you're not configuring a one-off task. And god knows, I've done plenty of those using bash, and python, and ruby, and..., and any combination thereof.

Yes, all the "pipelines" you build for editing text (esp. in programming context) can't hold a handle to actual specialized tools.

I don't know what you mean by "one-off task", of course you can save the commands you use most often. I think part of mastering vim is thinking about movements and commands in a more generalizable way, then macros are just second nature. Macros just make all the insane one-off editing tasks everyone runs into trivial.

This morning I needed to byteswap all the hex constants in several huge tables, I don't know if I've ever needed to do this before, and probably won't need to ever again. I did it in vim with a macro that took me seconds (something like qa2xlpj3hq1000@a).

Sure, this isn't for everyone, but one day you are going to want a minor variation on the operation your magic button performs... and I think you're going to have to take a swig of coffee and just sit there doing it manually!

I find this argument way more dubious than GP.

You're hiding a lot of qualifiers in phrases like "power user", "some types of text", "these types of tasks".

What is a power user? Exactly which types of text can't vim handle as well as other editors ? Exactly what types of tasks rarely occur?

"Proper" refactoring and context-aware selection are absolutely possible with a properly configured vim (or neovim) install, all while remaining free, open source and I daresay quite a bit slimmer than any Jetbrains IDE.

> What is a power user?

A user who has spent a lot of time with Vim, is intimately familiar with multiple ways vim handles text, and all the arcane shortcuts, and created their own workflows

And even then it depends. I've seen people spend more time craeating macros and replays than me on the same task using a simple tool like multiple cursors.

> "Proper" refactoring and context-aware selection are absolutely possible with a properly configured vim (or neovim) install

"Out of the box" beats "properly configured" for the absolute vast majority of users. And I've yet to see the "properly configured Vim" from the self-professed Vim masters that is to do anything faster than what I do with Idea on a daily basis.

I don't know, this sounds a lot like blub to me. "I've never seen anyone do anything with a charcoal stick that i couldn't do with my ballpoint." Or "I don't see why people like regex when code refactoring tools are so much smarter."

People say the same thing about Linux vs Windows in general, particularly the "for most users" straw man. We're not talking about most users, we're talking about users that care enough about a use case to put up with the time it takes to learn tooling.

If someone cared about things vim was good at (flexible, programmatic text editing), they'd be more likely to have switched to using it. The fact that your needs don't like up, that you don't appreciate the difference or don't care about it, e.g. because you mostly edit source files in a particular language well-supported by your IDE, rather than frequently needing to do one-off esoteric things to a wide variety of files with varying semantics.

Fwiw, i know vim well, have used it many years, and still frequently switch to an ide when doing things that the IDE was specifically designed to support.

> A user who has spent a lot of time with Vim, is intimately familiar with multiple ways vim handles text, and all the arcane shortcuts, and created their own workflows.

So - only when a vim user reaches this point do they become as effective as a non power user of IDEA? I can't agree. It is simply not necessary to understand more than a 10th of what vim can do to be productive with it. And the other 90% is there to be discovered when it's needed.

> And even then it depends. I've seen people spend more time craeating macros and replays than me on the same task using a simple tool like multiple cursors

Seems like cherry picking to be honest. Plenty of people find it fun and rewarding to learn and practice features like macros, but search/replace with confirmation is as fast or faster than editing with multiple cursors, and most users probably learn about it before going near macros.

> "Out of the box" beats "properly configured" for the absolute vast majority of users.

Seems like a different claim than your initial contention that Vim is not as capable a tool as an IDE.

But there are many well-maintained configurations of vim that are as trivial to install as IDEA, with as many features (and again, free and open source).

> And I've yet to see the "properly configured Vim" from the self-professed Vim masters that is to do anything faster than what I do with Idea on a daily basis.

It's only natural that you find it easier to conceive that the tool you use on a daily basis is more effective than one you don't. Same goes for me. We each have become very effective with the tools we use every day.

I freely admit to being biased toward the sort of Unix-oriented tools that taviso described in his comment, because at their core they are simple, performant and combine well with other tools (not to mention free and open source). Can IDEA claim more than one of these?

The author writes,

“my plain text emails, written with glorious 80 column limit, would be viewed with random line breaks on mobile clients”

He’s doing it wrong. You should write your emails with a 998 character limit. Only add linebreaks between paragraphs. If your paragraph is going longer than 998 characters, recast. This way, the client will break the lines properly and the reader won’t have to read a chaotic mess of random linebreaks. Your email will look good on phones and everywhere else.

I'm a fellow mutt user - I've always used ~80 column limit... it makes me wince thinking of removing it!

I do hear from non-nerd contacts asking about the line breaks, perhaps you're right, maybe it's time!

I used to do the same. Sometimes I would remember to squash my convenience linebreaks back down into real paragraphs for the recipient.

I assume you use vim or emacs for editing -- vertical movement between lines is more convenient than movement within a single wrapped line.

In vim, you can use gj or gk for vertical movement within a wrapped line.

At some point I decided to make the arrow keys more useful:

  map <silent> <Up> gk
  map <silent> <Down> gj

Try it. You’ll never go back.

Why 998?

It's part of the email specification. Look at https://www.rfc-editor.org/rfc/rfc5322#section-2.1.1.

That spec literally recommends 80 char lines.

> That spec literally recommends 80 char lines.

You mean this recommendation?

> The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC5321] if they actually cause information to be lost). Again, even though this limitation is put on messages, it is incumbent upon implementations that display messages to handle an arbitrarily large number of characters in a line (certainly at least up to the 998 character limit) for the sake of robustness.

Are there many user interfaces that can't handle more than 78 characters anymore? Even terminal windows wrap now. I'm inclined to believe that the 78 character recommendation really isn't that important anymore.

That said, I'm curious if the 998 restriction really is important too. That comes from here:

> The 998 character limit is due to limitations in many implementations that send, receive, or store IMF messages which simply cannot handle more than 998 characters on a line.

Are there many such implementations hanging around that can't handle more than 998 characters?

I don’t have hard information but I believe so. If you have a line with more than 998 characters you’re taking a risk that your email will be rejected. But I’m pretty sure there is never any problem with lines <= 998 characters, and it works far better on more devices than trying to break lines to fit some imaginary screen, which always ends up in a mess.

I used to use mu4e or notmuch for email, but now I know my readers massively benefit from formatting emails with html -- mostly for emphasis to make my long emails easy to digest and skim. And I can't live without the calendar integration in Outlook or Thunderbird. I'm okay with a terminal todo list, but for calendars I think it should be GUI.

I still use Emacs to compose emails. I just copy/paste to a GUI client when I'm done composing.

Try https://github.com/meli/meli/ it's mostly stable and doesn't have the problems described in the article. Development's on hold due to some personal factors but it's going to be picked up again.

I love mutt but there are plenty of better tools for composing emails. If I’m trawling through messages by the dozen I’ll use mutt, but if I’m composing I’ll still use iOS mail or outlook.office.com to write something that doesn’t give me away as being, deep down, a socks-and-sandals Unix Luddite.

It took me way too long to figure out that this article is about endowing mutt with the capability of sending HTML mails. Something I don't even care for, as the article correctly points out.

"How I send HTML mails with mutt" would have been a better title.