I've been using Mutt with Gmail for years to great effect, and would very much recommend the set up.
The one caveat that I should point out (because it's not mentioned in the article) is that you will probably never be fully rid of official Gmail clients. There is still no good mechanism to use some features with Mutt like thread muting, and these are essential to effective email these days. It's also often more convenient to read certain types of email (e.g. messages that are heavy in multimedia) from a client that supports graphics.
My usual habit is to read email in the web client or on mobile, and respond to or compose mail from within Mutt.
> There is still no good mechanism to use some features with Mutt like thread muting.
I use `collapse-thread` (Esc-v) on long threads I don't care about, but you're right this is less than ideal. New messages in the thread uncollapse it again, and there's no way to persist the collapsed state, so switching mailboxes or restarting mutt loses it.
Agreed, by far the best guide I've found. My setup, based on that guide + some tweaks is at https://github.com/cbracken/mutt for anyone who might find another sample useful.
Yes, I was looking into the whole offline sync setup but I am a big fan of keeping a clean inbox so I just went with the current setup.
Also, one advantage of this is that changes are real-time which means that if I check the gmail app on my phone messages are correctly moved, marked as read etc.
Like the post. What I did differently is to use fdm to fetch emails and store them locally. I've been using Mutt with Gmail for many years. The features I like most are:
- regex search
- faster actions (like batch delete, mark as read) using tag
- can use my editor to compose. I use emacsclient -nw and it's so easy to copy things from shared buffer.
- very easy to customize, for example, I want to see the timestamp as local time regardless of the sender's timezone, I wrote a smile Go program to do that https://github.com/wujiang/localize_mutt; I also run a cronjob to archive old emails.
I love to use the terminal—I'm a Vim and tmux user—but I was never really able to switch to Mutt. I often receive emails with attached images or HTML code. Maybe some Mutt user can share with me some of the reasons why they like it so much?
I am a 20+ year (al)pine user (without gmail - I host my own mail server) and I have a fairly decent attachment/images/links setup ...
First, I use ripmime to dump every single attachment to a folder with dated naming - and so if there is an email in pine with an attachment I want to view, I just web browse a simple apache directory listing and click it. It's not sexy, but it's fast and efficient.
Second, I have a terminal PDF reader installed on my system and defined in alpine as a helper app for pdf files. So I cannot read word or excel right in alpine but I can read PDF docs. So that's nice and slick.
Finally, I never actually click links in alpine, but I defined lynx as a web viewer anyway because that allows me to get the very simple "do you want to view this http link ?" prompt from alpine ... which I always say NO to, but not until I have copied the full URL which they display for me. Then I just open it in a browser.
Not trying to be snarky, but why not use something like Thunderbird (or whatever comes default on the OS of the machine that you're using) that will render out the HTML natively?
If he's anything like me, a fellow mutt user, he cares more about speed and the text itself than pretty columns. It's surprising how little you miss html, particularly when breezing through email at a rate of knots. Plus system resources. So many resources.
Depending on what kind of Word documents you get, you might be interested in trying terminal doc(x) to plain text converters. Last I checked they were fairly good for simple things.
In mutt's pager view (reading a message), hit "v" to see all the mime parts, j and k to select one, and enter to view it with the associated mailcap command. In my mailcap I'm popping up images in GraphicsMagick, and viewing rendered html pages in w3m. Pretty rare for me when that doesn't cut it -- most mail has a readable plaintext part or a w3m-readable html part.
> Maybe some Mutt user can share with me some of the reasons why they like it so much?
It lets me fully reside in "the world of text:"
- I can compose emails in my text editor (vim, like you) instead of a crappy textarea.
- Mutt feels much faster than gmail and other gui mail clients. The keyboard shortcuts are amazing.
- I can use tmux's activity monitor feature as a text-based growl notification for new mail.
- All my mail (300k+ messages over 10+ years) is available locally, offline, in Maildirs. It's searchable and pliable by the unix toolset, enabling all kinds of fun things like [1]. I use and recommend offlineimap.
- Control. Mutt has changed conservatively over the years. You can configure it to your liking, and be reasonably certain it will continue working to your liking. No "New Compose" crap here. Tools like mutt are a great long haul investment.
One thing I find seriously lacking with mutt: the folder-centric message index (instead of tag-centric or search-centric index). You can get by okay with mutt's searching and limiting, but if you're jumping between folders often, it kinda sucks. Reminds me, I need to revisit mutt-kz.
I like the idea of having a large mail archive available locally for searching, but what do you do for mobile access? The utility of being able to search 10+ years of quickly while AFK is very high. I'd love to have a synced local archive that resided entirely on the mobile device.
There's a commandline option to pass the document type to w3m: '-T text/html', I believe, confirm on the manpage.
It'll force any given file, or stdin, to be interpreted as HTML. It helps to remember that w3m was originally created as a generic file / directory browser. It's Web capabilities were somewhat incidental, though that's what it's largely used for now.
Mutt makes writing/reading/searching/managing email just really fast. Mutt also allows to pass the message body to an external program. This helps for formatting HTML mails. This is a snippet from my .mailcap file which renders HTML mail through lynx.
- Can easily deal with large volumes of email -- quickly tab through unread messages
- Highlights text from previous emails in a thread, making it easy to see who replied to what
- You can also set up highlighting for diffs, making it easy to review attached patches and change snippets
- Powerful search via external indexers (mu, notmuch)
- Keyboard navigation for everything (if you're using vim and tmux, then you're already spending most of your time with your hands on the keyboard, and having to fish for the mouse just to quicky reply to an email starts to feel really slow).
For handling HTML email, I use a two-pronged approach: for most email I use links browser to automatically render HTML as ASCII so I can view it directly in mutt; for email that has images or otherwise cannot be rendered sensibly with links, I have mapped a key to open it in a graphical browser (dwb for fast launching or Firefox+vimperator if I need to deal with login forms, etc).
iTerm2 (and I'm sure there's Linux equivalents) can display images inline in the terminal.
It would be cool if Mutt could be configured to support that, maybe through the w3mimgdisplay command. I think that's how [ranger file browser](https://github.com/ranger/ranger) does it.
Number one reason why I switched to mutt was after mailbox was discontinued, I wanted an easy way to move my mail between several organized folders (this requires 3+ clicks in gmail). Now I have keyboard shortcuts to move a message to my various frequented folders, and I can move through dozens of email in less than a minute.
mutt + offlineimap + gmail is fantastic. When I need to use their web interface it is painful. mu gives you almost instant search, but I almost never need to search email so I don't have that dialed in.
I use a similar set-up, but I had a really bad time making offlineimap sync work. In the end I switched to isync which was easier to configure. It has fewer features, but it has worked out great for me with `Flatten .` turned on in the configuration file.
Yeah. Offlineimap was a bear to get working right. I've heard good things about isync, but I don't really want to touch the house of cards now that it is all working.
Is it possible to use mutt and Gmail without enabling lesssecureapps? I know this post deals with some of those issues (gpg keys and whatnot), and Google strongly recommends IMAP/SMTP protocol users switch to OAuth 2.0, etc.
I was honestly surprised to see all this gpg setup, yet no mention of application-specific passwords. I've been using email clients with what google now calls an "App password" for years.
"application-specific passwords" are not actually restricted to a single application. You can restrict the scope (only has access to your emails, for example), but any application could use this password to access your emails.
Yes, I do it, but honestly, it is a pain. I didn't look too hard, but at first glance it seems there is no way to get a persistent token to work. Everytime you don't renew your token after 1800 seconds, you have to open the google developer web page and get a new one.
Anyone here coming from nmh, but prefer to use Mutt? I was wondering if Mutt is worth the switch since some things in nmh seem hard to keep up to snuff with the ever-changing www.
I tried alot years ago and loved it, but it had the huge caveat that it didn't write changes back to a maildir. This made it really hard to incorporate into a multi-device setup. Do you know if this has been added? I didn't see an obvious answer on the github page.
You mean write to the maildir sent folder? Or metadata like read and other tags? I don't have metadata sync but I bet there's a way to do it via xapian.
For multi-device, I use a MDA[1] on postfix that writes to a maildir, and that's rsynced to my various boxes. When I send, ssh pipes the msg to sendmail on the server, which copies it to the .sent folder.
Mutt doesn't do networking well. It was build to deal with Maildir and mbox on a local disk, not IMAP over the network. aerc is designed to just support IMAP, and it does networking on a second thread so issues there don't lock up the UI. aerc also supports multiple accounts. It also has (imo) better configuration and commands.
Can confirm. Long-term mutt-er who frequently switches between wired and wireless networks. I basically just ctrl+z any frozen mutt instance and start over. 'fg 1' brings up the first when back on the first network...
But overall love mutt and think aerc is a great initiative. Nice to have an inbuilt sidebar too! Beats recompiling mutt with sidebar patches.
Currently, terrible. It doesn't support those things at all. It doesn't even have an email reader, it just lets you browse subjects at the moment. It's very much in dev, and I could use some help :)
I intend to have excellent gpg support, decent search support, and no support for offline storage whatsoever.
The one caveat that I should point out (because it's not mentioned in the article) is that you will probably never be fully rid of official Gmail clients. There is still no good mechanism to use some features with Mutt like thread muting, and these are essential to effective email these days. It's also often more convenient to read certain types of email (e.g. messages that are heavy in multimedia) from a client that supports graphics.
My usual habit is to read email in the web client or on mobile, and respond to or compose mail from within Mutt.