Live data from Hacker News

The Homely Mutt

stevelosh.com

101–110 of 116 posts

Re: The Homely Mutt

#101
post #95
post #41

"...it’s got a lot of advantages over many other email clients." The advantages were never enumerated. Most of the article was spent teaching you how to program ^H^H^H configure the thing. What are the advantages?

What are the advantages? One advantage: you can configure mutt to behave just like vim (as far as shortcut keys go). If you don't use vim you won't understand. If you do use vim, having mutt use vim for editing combined with vim-ish hotkeys makes for a very powerful, simple, and enjoyable tool.

"If you don't use vim you won't understand."

Well, thanks for your insight but that was kind of a dick way to put it. What do you think is so hard to understand about the advantage of common key-bindings between applications?

Great trade-off though. You are such a cool hacker. Too bad you have to jump through hoops to view modern HTML formatted email. Hey you've got some vim key bindings though. Totally worth it.

Re: The Homely Mutt

#102

I would miss HTML formatted emails after a while. A promising alternative is Muttator ( http://www.vimperator.org/muttator ). Muttator is from the same team that made Vimperator, a Firefox add-on that changed the way I browse the web.

Muttils[1] makes it easier to deal with html email in mutt, and has a bunch of other goodies as well. I hit one keystroke and I'm looking at the html message in my web browser.

[1]http://lee-phillips.org/muttheaven/

Re: The Homely Mutt

#103
post #96
post #81

This is exactly the sort of article I want to see on HN. It's thorough, and instead of dropping a pile of dotfiles on github and saying "here you go", Steve goes through everything and explains what's what and why.

"Coming Home to Vim" is a pretty good post too from Steve: http://stevelosh.com/blog/2010/09/coming-home-to-vim/

That's just awesome. My vim just got a hell of a lot better just from reading that (which probably tells you something about the level I've been operating at for the last 15 years or so).

Re: The Homely Mutt

#104
This was great. I'm a big fan of mutt. For all the advances in GUI software, my favorites remain at the console: mutt, slrn, newsbeuter, links, and so on.

I wrote a guide to Mutt as well. It's geared for the less-tech inclined than your typical ycombinator - but if you know any Linux/BSD noobs interested in getting their feet wet, my Woodnotes guide will give them a gentler splashdown than this advanced guide to setting up Mutt. http://therandymon.com/content/view/42/98/

Well done, Steve - great work on this article.

Re: The Homely Mutt

#105
post #100
post #56

Earlier quoted context omitted.

This is my fault for not explaining why I wasn't going to look into it more. According to the features it has listed, it offers me no obvious advantages to my current tools and claims to be difficult to setup and configure. Beyond that, if you truly want adoption for a tool, you'd invest time into making sure that you remove the obstacles of someone utilizing it. This is a tool that hasn't had any major releases sinc…

As silly as it sounds I think most of these tools are just being overly appreciated by a group who (at least sub-consciously) think of themselves as cool/badass for having some hacker-style terminal in front of them, you know it's true. Hit me all you want, but the same applies to Vim and Emacs for a large percentage of people who admire these tools. People religiously defend them just because they are 20 something y…

Add in that they run it from a Mac and I'm on-board with you.

lol.

Re: The Homely Mutt

#106
post #85
post #75

Earlier quoted context omitted.

Don't forget to launch any secondary instances of mutt with -R, or you'll encounter conflicts. I've been searching for the right way to launch the editor in a new tmux pane, although apparently getting that to work smoothly would take a patching effort.

I launch innumerable copies of mutt without -R, and have never had any conflicts. Like the original poster, I'm using offlineimap and maildir's entirely. What kind of conflicts do you get?

It's something I read when I was getting started with mutt.

Perhaps is much less of a deal than I thought, after giving a cursory Google I can't seem to find what I read that gave me that impression and I don't see any major warnings not to.

Re: The Homely Mutt

#107
post #51

Earlier quoted context omitted.

MIME html emails will have a plain text part that will be displayed properly. For pure HTML, you can always have mutt open them in a web browser.

A terminal still can't render images. Unless you're doing some level of framebuffer shenanigans, that is, but I'd wager most people work on a GUI with terminal windows, not full screen terminal VTYs. We've got this wonderful invention called the graphical user interface.. why not leverage it?

> A terminal still can't render images.

How often do you see images in your emails?

They are usually remote linked content, so your client disables them for privacy reasons. How often do you really click "display images in this message" versus "meh, I got the message and I can spare the rounded corners on this advertisement and instead not send a req back to their server notifying them I've read it".

But I get what you're saying. Without HTML emails we'd all still be looking at those ">" characters for quoting. Hideous. At least now we got dark blue vertical bars. I for one couldn't live without them. That's progress!!

Re: The Homely Mutt

#108
post #41

"...it’s got a lot of advantages over many other email clients." The advantages were never enumerated. Most of the article was spent teaching you how to program ^H^H^H configure the thing. What are the advantages?

A small enumeration of mutt's advantages in my experience:

- It's small, fast, and light. I have a mail client that runs in a terminal window (or console session, or remote SSH session). Navigation, search, and controls are all keybindings. It's fast to fire up, compose, edit, navigate, filter, and send.

- Threading. Mutt's thread-handling is second to none (though strongly influenced by newsreaders such as tin and slrn). Threads may be expanded, collapsed, marked read, navigated, joined, and split. Gmail's "conversation view" is a pale imitation.

- The "limit search" feature really rocks. If you want to find a mail from, say, the 14th of the month forward, from bigboss, subject "widget": "~l ~d 15- ~f bigboss ~s widget". You can filter by date ranges, add either AND or OR keyword matches, search by text, etc.

- Once you've identified a set of messages to look at, you can scan through them very quickly via keyboard navigation. Very useful if you're dealing with a large number of automatic / system-generated mail, though others can be handled as well. Literally: scan several hundred messages in a matter of seconds, looking for major differences.

- Tagged message management. Messages may be tagged ('' key), either individually, or using filter/match rules. Say you've looked at all your Nagios alerts and want to move them to an archive or delete them: "T.;s". Much faster than the equivalent in Gmail or any other GUI client I've used. This with limit search is the killer feature for me.

- In-line handling of MIME attachments. There are console-mode readers for many document formats, including HTML, Word docs, spreadsheets, and presentations. Even if they don't give you a fully-formatted view of the document, you can get the gist of meaning without firing up a full-fledged GUI app.

- Spawning MIME attachments. If inline isn't sufficient, there's the attachment index (for mails with attachments) and you can launch these using the handler of your choice (specified by your mailcap file). Attachments may also be saved from the index individually or collectively.

- Adding attachments. Similar to the MIME viewer -- this is actually faster and more flexible than most GUI tools (in particular, Gmail). You can also add messages as attachments, not just files.

- Speaking of GMail: if you do want to view a message in its GUI wholeness, just pop open a browser and view it there through GMail. IMAP means you've got a synchronized set of folders locally and remotely. You can also share IMAP access with a local GUI client (KMail, Thunderbird, Evolution, etc.). This is particularly helpful for calendaring (I'm not aware of a MIME handler that will add ical event to a calendar).

- Comprehensive PGP support. It's highly unappreciated and underutilized, but both encryption and signatures are supported. At the very least you can confirm signatures readily on security bulletins from most major Linux distros.

- Incorporated address books for completion. Typically via an included 'aliases' file. Start typing a name, hit 'tab', and a screen of completions appear. Do this right an you can grab a list of related names in one pass. You can also alias lists of addresses you use frequently (say, "family" or "engineering team" or "zombie apocalypse task force").

Re: The Homely Mutt

#109
post #99

Earlier quoted context omitted.

You can launch a compose session from any terminal. "mutt -s 'subject line'" will prompt for recipient(s) and drop you into an editor for composing. You can even pipe output straight to mutt: df ¦ mutt -s "disk utilization" foo@example.com

Hm, I might follow that idea (open in a new terminal window or split screen). I'd somehow have to get the original message as a quote for the new message.

You can always open the mailbox first and grab the message you want to reply to:

    mutt -Rf 
... will open the given mailbox in read-only mode (so as not to update read flags and such).

In practice, I generally run mutt within screen, with multiple frequently-accessed mailboxes open. I switch mailboxes by moving between screen buffers.

Re: The Homely Mutt

#110
post #85
post #75

Earlier quoted context omitted.

Don't forget to launch any secondary instances of mutt with -R, or you'll encounter conflicts. I've been searching for the right way to launch the editor in a new tmux pane, although apparently getting that to work smoothly would take a patching effort.

I launch innumerable copies of mutt without -R, and have never had any conflicts. Like the original poster, I'm using offlineimap and maildir's entirely. What kind of conflicts do you get?

Default / typical behavior is for mutt to update the mailbox message state (new, unread, read, replied) when closing the mailbox. Using the -R flag prevents this behavior.

Forgetting to do so is more an annoyance than an End of the World Event, but it's an annoyance which can be avoided with a really simple flag use.

Post reply on HN