Mutt’s secret sauce (2017)
nosubstance.me
nosubstance.me
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.
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.
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.
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.
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).
This claim is dubious at best. While a power user may, in fact, be reasonably fast with some types of text, for most users these types of tasks rarely occur, are already a part of the editor, or can be as quickly done with existing tools.
(For example, context-aware selects and proper refactoring in IDEA beat anything vim/emacs have to offer any day, and twice on Sundays)
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!).
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.
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!
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.
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.
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.
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?
“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 do hear from non-nerd contacts asking about the line breaks, perhaps you're right, maybe it's time!
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> gjYou 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 still use Emacs to compose emails. I just copy/paste to a GUI client when I'm done composing.
"How I send HTML mails with mutt" would have been a better title.