6 ms·
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
by MontyCarloHall 4y ago
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.
- leephillips 4y agoI’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/ 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.
- Zhyl 4y agoThe 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.
- dmitriid 4y ago> 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 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)
- mpalmer 4y agoI 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.
- dmitriid 4y ago> 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.
- deleted 4y ago[deleted]
- mpalmer 4y ago
- k2enemy 4y ago>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.
- MontyCarloHall 4y agoGood catch! I edited my original post to reflect this.
- flenserboy 4y agoCan'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.
- tra3 4y agoI 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.
- mattarm 4y agoIn 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).
- deleted 4y ago[deleted]