[HN Gopher] Mutt's secret sauce (2017)
___________________________________________________________________
Mutt's secret sauce (2017)
Author : mooreds
Score : 47 points
Date : 2022-07-22 13:22 UTC (1 days ago)
(HTM) web link (nosubstance.me)
(TXT) w3m dump (nosubstance.me)
| clircle wrote:
| 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.
| mr_mitm wrote:
| 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.
| [deleted]
| leephillips wrote:
| 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.
| taviso wrote:
| 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!
| leephillips wrote:
| Try it. You'll never go back.
| quesera wrote:
| 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
| CogitoCogito wrote:
| Why 998?
| leephillips wrote:
| It's part of the email specification. Look at
| https://www.rfc-editor.org/rfc/rfc5322#section-2.1.1.
| gorgoiler wrote:
| 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.
| MontyCarloHall wrote:
| 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.
| Zhyl wrote:
| 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.
| k2enemy wrote:
| >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 wrote:
| Good catch! I edited my original post to reflect this.
| [deleted]
| mattarm wrote:
| 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).
| flenserboy wrote:
| 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.
| tra3 wrote:
| 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.
| dmitriid wrote:
| > 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)
| taviso wrote:
| 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!).
| dmitriid wrote:
| 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.
| taviso wrote:
| 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!
| mpalmer wrote:
| 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.
| dmitriid wrote:
| > 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]
| leephillips wrote:
| 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.
| epilys wrote:
| 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.
___________________________________________________________________
(page generated 2022-07-23 23:01 UTC)