Mutt releases version 2.0 | Hacker News Reader

Mutt releases version 2.0

lwn.net

139 pointsleephillips40 comments

https://news.ycombinator.com/item?id=25019901

More Mutt from 3 months ago: https://news.ycombinator.com/item?id=24173676

> One of Mutt's unusual strengths is that it actually displays message threads correctly. When people complain that they have trouble following email conversations involving groups of people, what they typically mean is that they are using a client such as Gmail that does not properly display the reply structure of email messages. When an email user hits the reply key, an In-Reply-To header should be added to the email. Mutt refers to these headers, and to the related References header, to keep track of which messages replied to what, and builds a tree to show the structure of the conversation. Some other mail clients attempt to construct this tree using only the Subject header

This seems somehow wild to me. Why don't other email apps use the appropriate header fields? Why do they even try to use the subject field? Why do they insist on quoting the whole thread text below the message body? Why not do all this the proper way?

Good questions! For these reasons and others, such as the lack of any concept of mail bouncing and the inability to even edit headers, I don’t regard Gmail as being an email client. Instead, I think of it as a kind of toy program that was designed to demonstrate what could be done with javascript, and it was an impressive demonstration when it came out.

I’ve had discussions with various groups that I’ve worked with where some people get the idea to move to Slack or some other platform, because email is not working well enough. When I ask them what the problem is with email, they start describing the shortcomings of...Gmail. They actually have no problem with email, they’ve just never used an email program.

Even more fun when a workplace disallows anything than the gmail web client... drives me a bit nutty.

As someone who just joined a small startup using google accounts, do you have any good recommendations for desktop/email clients? Prior company used outlook.

Have you tried Thunderbird?

Always thought about it but never followed through, thanks for reminding me to try it.

Does it support labels? Using labels instead of folders is among the killer-features I love GMail for.

notmuch or mu4e are both quite good for email in general, including gmail. The setup isnt always the easiest, but worth it once you get the flow imho. Thunderbird if you like guis.

You can give the basic HTML version of Gmail a try:

https://support.google.com/mail/answer/15049

because normies can barely understand the concept of a thread, much less quoting

the only problem with this is that gmail does show the proper, header-referenced, thread structure. as well as subject “referenced”.

anyway one shouldn’t blame gmail. it’s outlook that forced gmail’s hand.

furthermore, like a bike vs car accident, you can be correct and still dead. mutts insistence of “keeping the thread” when users change the subject is “correct” yet still dead. 99% of users — aka normies — reply to an existing message when starting a new thread. changing the subject in almost all cases is intended to create a new thread, not a new subthread.

one has to work with the users you have, not the users you wish you had.

FWIW, in mutt tapping # on a message that should have been a new thread will make it such. And you can rejoin messages where people sent a new mail instead of a reply with &.

Things like this, along with tools like t-prot¹, allow you to live the mail you want while still interacting with others ;)

¹ http://www.escape.de/~tolot/mutt/

i'm not criticizing mutt at all here. in fact i am going to try it out for awhile. i never used mutt back in the day, as i was always a gnus user.

what i find fault with in the lwn article is the "attack" on gmail. gmail has its reasons for doing the things it does, good reasons.

i actually liked mulberry quite a lot. especially the feature where 'reply' brings up an interstitial allowing you to select to/cc/bcc for each recipient. another aspect of email completely lost on normies. but it's day has passed.

Author here: I understand your point, but I disagree that Gmail’s reasons are good reasons. Partly this is a difference in philosophy I suspect; we should all try to help each other to become better, and Gmail’s pandering to users’ poor habits just enables them to avoid gaining understanding that would help them in the long run. Another reason is that the Gmail type of threading simply doesn’t work in practice, especially when the conversation has more than three participants. I know this because of the way people try to find a “better” way by moving away from email, when a good portion of their frustration is due to the difficulty in following conversations, specifically because they are using Gmail. They have no idea that email already offers them what they need, because they’ve never used an actual email client.

Thank you for chiming in.

I take your point, very well. But a fundamental disagreement we have is your generous opinion of the 90 %ile user's ability and desire to become an email expert. The loss of that battle was recognized in September 1993.

gmail didn't relinquish its duty to educate users as it became popular; it became popular (in part) because it did things in a simpler way, that users didn't have to "learn" how to use. The vast majority of folks do not care about such trivialities as following a thread. It requires forethought that they do not want to invest.

You have to meet users where they are at. One can wish for better users, sure. That's not a winning strategy.

As well, I still maintain it's unfair to pick on gmail. They had to follow Outlook. Outlook willfully broke threads for other MUAs by not including In-Reply-To headers. That was just evil. At least gmail generates In-Reply-To and References headers! Which Outlook drops. Outlook should be the bogeyman for your article, not gmail!

You are absolutely correct that Gmail followed a winning strategy; they’ve won, after all. The same is true of Facebook. From the point of view of corporate success, they are doing the right things. My point is just that these are not good things, in the larger sense.

Thank you for informing me about the role of Outlook in this. I used Gmail as my example because it seems to be taking over, at least for “normies”, as you call them. So the average person’s idea of what email is comes from experience with Gmail. It’s possible I’m underestimating the importance or prevalence of Outlook, as I deal less with corporate types than academic and publishing types.

Microsoft threads by subject (and will generate a new thread id if you change the subject in a reply) because they found a large minority of their users didn't use the address book, but instead searched for a recent email from the person they wanted to send to and replied to that, after changing the subject.

> because they found a large minority of their users didn't use the address book, but instead searched for a recent email from the person they wanted to send to and replied to that, after changing the subject.

That's exactly what I always do. And I don't do that to find the address. I do that intentionally because I actually want the whole history of communication (even if it spans years and hundreds of messages) with a particular party to be a single huge tree thread.

> This seems somehow wild to me. Why don't other email apps use the appropriate header fields? Why do they even try to use the subject field? Why do they insist on quoting the whole thread text below the message body? Why not do all this the proper way?

This all started with Microsoft Outlook back in the '90s. At that time, most email clients, even the GUI ones did handle threading using the References and In-Reply-To headers (even Outlook Express oddly enough). IIRC, the online webmail clients took the same approach that Outlook did in terms of message threading and quoting. As they became more popular and desktop clients fell by the wayside, the Outlook convention took over. FWIW, Thunderbird is one GUI based email client that also properly displays threaded messages.

More recently, email clients have introduced the conversation view where they can display a thread as a conversation by only showing the parts of the series of messages before the quoted original message. This has an unfortunate side effect of essentially not displaying any message where someone decides to trim quoted material and post their responses inline. In a client that expects top-posted responses, an inline response shows up as a blank message (making the recipient think that you sent a blank email by mistake).

But I do find it interesting that people want to treat email like a synchronous chat with a single thread of messages, but people want to have threaded conversations in chat clients like Slack.

I personally find the concepts that the Mutt UI implements to be amazingly efficient for any task that requires human review of individual items in a set.

For example, I am a moderator for a popular subreddit. I've written a Python app that uses the requests module to interact with the Reddit API and displays the items on the mod queue via curses, Mutt-style. I use columns to give me succinct metrics on each element, such as the number of times the author of a submission posted the same URL across other subreddits (that's a strong indication of spamming). I move around the list with vim-like key bindings (i.e. k/j for up/down), and when I want to approve a post or comment, I just hit 'a'. If I want to remove a post or comment and ban the author, I just hit 'b'. If I want to dig in to the post or comment to get more data about it, such as view its full contents along with all the reports on the item, I just hit space or enter. From there I can hit one of the usual keys to approve, remove, etc.

Since I'm a huge fan of instant UI feedback, I immediately remove the item from the list once I've hit a keystroke to take action on it. I asynchronously schedule the Reddit API call on a queue that implements the action, making sure to .join the queue on the app quit path so if I'm feeling especially twitchy about blasting through the mod queue and leaving before all the API calls can complete, I don't leave them dangling.

Any time I have any tasks at work that require manually making quick-fire decisions about largely homogeneous tasks, I routinely evaluate how hard it is to hack up a similar Python+requests+curses app to mimic Mutt. It's addictive. It's also mildly infuriating when someone builds a tool and forces you to use their "super special value-add web UI" without providing a stable and documented RESTful API.

Even if I can funnel only 90% of the stuff through my Mutt-like app and need to resort to the web UI for 10% of more special-case items, I still count that as a big win for my personal productivity (and sanity).

Interesting! I wonder how far one could get using Mutt itself, rather than coding a special-purpose curses program for each situation. In other words, convert whatever data you have into an mbox format, and use Mutt macros to take actions. Just thinking out loud here.

This seems to be a use case for Emacs.

Uhh this sounds awesome. Is it open-source? Can I find it somewhere?

Okay, but only because people keep asking:

https://github.com/SnakeyHacker/modpy/blob/main/main.py

I'm not proud of it. It's completely undocumented. I'm smack in the middle of completely rewriting what I had yesterday, and I haven't tested it in its current state. I've discovered PRAW and am trying to use it rather than make direct requests to Reddit's API. I'm not yet convinced that's a good idea. So it's almost certainly somehow broken right now. I can't promise I'll maintain it or pay any attention to bug reports or pull requests.

But hey, sometimes random code on the internet just needs to be random code on the internet. Maybe it can inspire someone more competent and dedicated to a project like this to fire something up.

If you don't need to work with images or formatted content, Mutt is far superior than Gmail and other webmail solutions. There is no perceptible delay, everything is happening instantly. I feel like I can answer dozens of emails in an hour and keep an empty inbox just because the experience is so smooth.

OK for the limitations about "formatted content" (these limitations are a feature to many people). But images and other file attachments are much easier to deal with in mutt than in gmail. They are just seamlessly opened by whatever image viewer you have chosen.

And you can put a shell pipeline in your mailcap file, so you can pre- or post-process your attachments as well as simply viewing them.

The two things that I had trouble with last time I used Mutt were calendar invitations from outlook or google calendar, and html pages (without opening firefox). Any suggestions on best practices?

For HTML, set

    auto_view text/html

in your startup file, and Mutt will consult your mailcap file to see what viewer you prefer. It will use that (lynx, w3m, etc) to display the HTML email in the pager as a default.

For calendar invitations: I've never tried to integrate that, but if they are attachments with a mime type, you can put instructions for processing them in the mailcap as well.

I have it set for text/x-patch text/x-darcs-patch along with a macro pager. Could do git, too, if you receive pull requests or patches often via e-mail.

Is there anything that has a clean and responsive viewer that supports HTML/formatted email with images, with an efficient keyboard-driven interface like mutt/notmuch/etc? Ideally, I would like my mail storage to be separated from indexing to be separated from access interface. I don't know why the graphical programs don't modularize the problem space that way.

Have you looked at astroid before? https://astroidmail.github.io/

Wow, astroid seems quite close to what I had in mind. I'll definitely give it a try -- thanks!

Seems also like it is not actively maintained currently, but I'm hoping it's probably feature-complete and stable enough to be in mostly maintenance mode. For anyone else who might be interested: https://github.com/astroidmail/astroid/issues/669

I'm not sure whether Thunderbird would meet your criteria, but there are a number of keyboard bindings and it can handle HTML messages reasonably well (especially if you set the view option to plain text).

I've been wanting to transition off fastmail and google apps mail for a while to mutt but sometimes I get email with attachments and images and I still don't understand what the best practice is to deal with those. I'm on debian buster. I also need to migrate like 50 gigs worth of email. Some of that is in those 2 services and some of that in mail folders on Mac OSX.

Agreed. I used mutt for all my email for a good six years or so until about 2012. However, all the HTML mail with no plaintext version that I was getting killed it for me.

There's .mailcap and dumping the HTML through w3m trickery that I know about now that probably bears revisiting mutt.

The article has explained to me nicely why I seem to get disorientated switching from my native mutt to Gmail webmail. I'd also noticed this threading issue in outlook when two emails without subject lines were threaded together.

The amount of time I've spent on my old .muttrc file is almost embarrassing...

Reply on news.ycombinator.com