The Homely Mutt(stevelosh.com)
stevelosh.com
The Homely Mutt
http://stevelosh.com/blog/2012/10/the-homely-mutt/
115 comments
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/
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).
It would be great if someone could write good text email client. I recently tried some old ones I used in the 90s again, and the quality of software has improved a lot since then.
Mutt:
- gets SSL errors with MS Exchange (gnu bug?), doesn't retry the connection and then stops displaying all your email.
- could never get html to text rendering working, almost all emails blank
- gave up on mutt...
Alpine:
- did actually covert html emails to text fine, most emails are readable
- no key rebindins (sic), I have ^T bound to new-window in tmux, too bad that's the only way to run spell check in alpine is to press ^T
- lose connection to IMAP server causes already downloaded mail to no longer be displayed on the screen
- quirky LDAP lookups, I can't type peoples full names, only their login names, then it resolves them fine
- tried to put my IMAP folder first on the list in the config file to make it faster to get to my inbox, crash
- tried to have it startup in my inbox using the startup key sequence, crash
- if there's one letter in my drafts folder, it asks me every time if I wan't to continue it when I compose a new message
- asks me every time if I want to reply to everyone, and if I say yes, it includes me(!?) so I get a dup email
- has pine's legendary inconstant key bindings (or is that a feature?)
- sending a message hangs the whole client until it's been sent
- no real concept of a deleted folder, just puts a D next to it and leaves it displayed on your screen, so you have to expunge manually if you don't want it to clutter your screen
- all in all, alpine is usable though, but there's plenty annoying things in it we used to think were normal back when pine was popular.
Mutt:
- gets SSL errors with MS Exchange (gnu bug?), doesn't retry the connection and then stops displaying all your email.
- could never get html to text rendering working, almost all emails blank
- gave up on mutt...
Alpine:
- did actually covert html emails to text fine, most emails are readable
- no key rebindins (sic), I have ^T bound to new-window in tmux, too bad that's the only way to run spell check in alpine is to press ^T
- lose connection to IMAP server causes already downloaded mail to no longer be displayed on the screen
- quirky LDAP lookups, I can't type peoples full names, only their login names, then it resolves them fine
- tried to put my IMAP folder first on the list in the config file to make it faster to get to my inbox, crash
- tried to have it startup in my inbox using the startup key sequence, crash
- if there's one letter in my drafts folder, it asks me every time if I wan't to continue it when I compose a new message
- asks me every time if I want to reply to everyone, and if I say yes, it includes me(!?) so I get a dup email
- has pine's legendary inconstant key bindings (or is that a feature?)
- sending a message hangs the whole client until it's been sent
- no real concept of a deleted folder, just puts a D next to it and leaves it displayed on your screen, so you have to expunge manually if you don't want it to clutter your screen
- all in all, alpine is usable though, but there's plenty annoying things in it we used to think were normal back when pine was popular.
I have been using Alpine/Pine for almost 13 years, and agree with most of your concerns. However, some of these can be controlled using the settings.
- Full name search in LDAP work correctly. Have you set name, surname, and given name attributes correctly in your LDAP setup.
- I exclusively used IMAP and have had no troubles with IMAP folder being fist in the list.
- Starting in the inbox (using key sequences) has always worked for me.
- Reply all does not include me in the Cc. Have you tried setting up alternate addresses field in the settings.
For HTML emails, I have set w3m as my html viewer. w3m works better with complex layouts in html.
- Full name search in LDAP work correctly. Have you set name, surname, and given name attributes correctly in your LDAP setup.
- I exclusively used IMAP and have had no troubles with IMAP folder being fist in the list.
- Starting in the inbox (using key sequences) has always worked for me.
- Reply all does not include me in the Cc. Have you tried setting up alternate addresses field in the settings.
For HTML emails, I have set w3m as my html viewer. w3m works better with complex layouts in html.
- LDAP: it's a corp AD server, cn, name and sn are all set correctly from what I can tell.
- Maybe CentOS 6.3 ships with a bad build or lib that causes it to crash. I'm using alpine-2.02-3.el6.x86_64.
- Setting the alternate address fixed the replying to myself issue, thanks!
- I'll give w2m a shot too. ;-)
EDIT: I suspect the crashes when going into the mailbox are due to it requiring me to enter a password.
- Maybe CentOS 6.3 ships with a bad build or lib that causes it to crash. I'm using alpine-2.02-3.el6.x86_64.
- Setting the alternate address fixed the replying to myself issue, thanks!
- I'll give w2m a shot too. ;-)
EDIT: I suspect the crashes when going into the mailbox are due to it requiring me to enter a password.
The day I need to make this sort of power-over-interface trade-off for reading email is the day I stop using email.
I use a similar setup, but I've been bitten by having Mutt and OfflineIMAP accessing the same Maildir concurrently. So instead, I run a local copy of Dovecot to expose a local IMAP server that both Mutt and OfflineIMAP talk to my Maildir through. This also means that I can trivially set up things like Thunderbird or MacBiff, using the same local IMAP server. Rube Goldberg would be proud.
I do the same, run dovecot, for essentially the same reasons.
It's not Rube Goldberg, it's separation of concerns: dovecot/imap for message serving and storage, and $CLIENT for mail access and processing.
Every so often I get pissed off at my mail client, run up the black flag and start slitting mail client throats[1]. In fact this article started me off on my biannual "doesn't anything not suck" tour, this time looking at claws, alpine and mutt. Anymore though, I just don't give a meh for intricate configuration.
One thing would make me want to spend a day in feverish configuration: if mh ("ah, mh") would do imap. I loved mh back in the day, when there was virtually no interface, just a collection of command line programs. Unfortunately it's pop-only and plain text only, far as I can tell. I have this fantasy of finding the source and ...
[1] http://www.quotationspage.com/quote/34585.html
It's not Rube Goldberg, it's separation of concerns: dovecot/imap for message serving and storage, and $CLIENT for mail access and processing.
Every so often I get pissed off at my mail client, run up the black flag and start slitting mail client throats[1]. In fact this article started me off on my biannual "doesn't anything not suck" tour, this time looking at claws, alpine and mutt. Anymore though, I just don't give a meh for intricate configuration.
One thing would make me want to spend a day in feverish configuration: if mh ("ah, mh") would do imap. I loved mh back in the day, when there was virtually no interface, just a collection of command line programs. Unfortunately it's pop-only and plain text only, far as I can tell. I have this fantasy of finding the source and ...
[1] http://www.quotationspage.com/quote/34585.html
I'd recommend compiling mutt without POP3/IMAP/SMTP support for this reason. I use this approach in [mutt-kiss][1] (Arch Linux AUR package).
[1]: https://github.com/tlvince/pkgbuild/tree/master/mutt-kiss
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.
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.
Great article and very timely for me, I just got Mutt working this weekend with my Gmail account. Picture of setup (showing Spam folder).
http://i.imgur.com/l4atq.jpg
I haven't added all the features the author pointed out (like server-side search) so excited to make it even better.
http://i.imgur.com/l4atq.jpg
I haven't added all the features the author pointed out (like server-side search) so excited to make it even better.
Anyway to make mutt(or any cmd mail reader) use the Mail.app database, stored in ~/Library/Mail? I already have Mail.app configured, and it has downloaded all my gmails accounts into the plain text emlx format? Also have 10gb+ of mail, and rather not have two copies of it.
I recommend mu (http://www.djcbsoftware.nl/code/mu/) to search emails. It can be integrated with mutt. But if you are an Emacs user then it even provides a mail client (mu4e).
And you can write scripts for it in Guile.
And you can write scripts for it in Guile.
"...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?
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<archive-name><return>". 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").
- 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<archive-name><return>". 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").
Excellent, thank you very much for that. I may actually spend the time to learn how to use mutt.
The biggest advantage for me, personally, is that it's so customizable and open source. Every last aspect can be tweaked to my liking.
Yet I've tried at least twice in the past to fix the sidebar patch, with 0 response from the maintainer. I'm not really interested in trying to push my fixes to each distribution that is using the sidebar patch.
E.g. try various combinations of "help = yes/no" and "status_on_top = yes/no" with the sidebar enabled. It's obvious that someone wrote it just to fit their configuration.
E.g. try various combinations of "help = yes/no" and "status_on_top = yes/no" with the sidebar enabled. It's obvious that someone wrote it just to fit their configuration.
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.
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.
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.
I would also recommend people look into notmuch.
http://notmuchmail.org/
http://notmuchmail.org/
Tried notmuch a while back, ended up going back to mutt. If you're an emacs user the notmuch mode may work well for you. The notmuch.vim plugin, OTOH, leaves a lot to be desired.
More promising is this fork of mutt that adds notmuch support:
https://github.com/karelzak/mutt-kz
More promising is this fork of mutt that adds notmuch support:
https://github.com/karelzak/mutt-kz
"Notmuch is not much of an email program. It doesn't receive messages (no POP or IMAP support). It doesn't send messages (no mail composer, no network code at all)."
notmuch doesn't replace mutt, you use it with mutt/offlineimap etc as your mail indexer, which makes massive mail archives instantly searchable.. (and does this extremely well)
I suspect this what the grandparent was referring to, it's not intended as a mutt replacement, so to complain that it doesn't replace it well is a bit unfair
notmuch doesn't replace mutt, you use it with mutt/offlineimap etc as your mail indexer, which makes massive mail archives instantly searchable.. (and does this extremely well)
I suspect this what the grandparent was referring to, it's not intended as a mutt replacement, so to complain that it doesn't replace it well is a bit unfair
how does it compare to mairix? http://www.rpcurnow.force9.co.uk/mairix/
(notmuch is mentioned in the original link, btw)
(notmuch is mentioned in the original link, btw)
I can't speak about notmuch (haven't tried it), but maildir-utils/mu[1] compares well to mairix. In particular, I think it's under more active development currently.
[1] http://www.djcbsoftware.nl/code/mu/
[1] http://www.djcbsoftware.nl/code/mu/
I use maildir-utils instead of notmuch as an indexer; notmuch had odd failure modes for me that weren't worth trying to debug.
mutt can also use IMAP/SSL directly, and I do that for some accounts, where I don't want to have local storage.
mutt can also use IMAP/SSL directly, and I do that for some accounts, where I don't want to have local storage.
I second the suggestion of maildir-utils/mu[1].
Here's my setup for that, in case anyone is interested: https://gist.github.com/45e318c68eb5a52e1646. It's essentially a cronjob (LaunchAgent on OSX) that calls a shell script to update the index periodically, plus a few macros to make searching from within mutt easier. To use this, you'll need to create a "Search" folder for maildir-utils to store results in.
[1] http://www.djcbsoftware.nl/code/mu/
Here's my setup for that, in case anyone is interested: https://gist.github.com/45e318c68eb5a52e1646. It's essentially a cronjob (LaunchAgent on OSX) that calls a shell script to update the index periodically, plus a few macros to make searching from within mutt easier. To use this, you'll need to create a "Search" folder for maildir-utils to store results in.
[1] http://www.djcbsoftware.nl/code/mu/
I doubt I have the need to customize GMail to justify doing this amount of work...but this was a very well put-together guide that goes beyond just "how-to-replace-Sparrow" to showing the underpinnings of how e-mail works and the thought process behind a hacked-together interface and service. I'm bookmarking this as an example of a thoroughly useful and informative guide. Thanks for making this.
Yes, very well written.
I do prefer offline e-mail and I actually use Claws under Linux, an X11 port is available for Mac OS
Seems to provide similar functionality.
I do prefer offline e-mail and I actually use Claws under Linux, an X11 port is available for Mac OS
Seems to provide similar functionality.
If you don't want to store your mail locally, but want nice search functionality, for Google Mail users there's this patch:
http://people.spodhuis.org/phil.pennock/software/mutt-patche...
It'll do search server-side, which means that you have Google's full text search without storing mail locally.
http://people.spodhuis.org/phil.pennock/software/mutt-patche...
It'll do search server-side, which means that you have Google's full text search without storing mail locally.
The weekend has just passed and you submit this on a Monday? Really? Now I'm going to wake up tomorrow, heavy with sleep after spending the wee hours tweaking my configuration and trying out "contacts", "offlineemap", and the sidebar patch (that I thought I didn't want).
Thank goodness I already have mutt installed and configured (almost) to my liking.
Thank goodness I already have mutt installed and configured (almost) to my liking.
if you want to use your CardDAV address book with mutt, you might want to try out pycarddav http://lostpackets.de/pycarddav/ . If you want features like write support, try the write_support branch from github https://github.com/geier/pycarddav/ (you can not really edit vCards just yet, but you can add email address directly from mutt)
My dotfiles are online if anyone wants to take a look at the actual configuration I use:
https://bitbucket.org/sjl/dotfiles/
https://github.com/sjl/dotfiles
https://bitbucket.org/sjl/dotfiles/
https://github.com/sjl/dotfiles
Good post, thanks!
Do you (or anyone else reading this for that matter) have any insight on how gmail -> imap works with labels when a single message has multiple labels? For example an email may be tagged with "clients" "$JOBNAME" and "receipt". Does it put multiple copies of the message in the local cache, or does it do a hard link, or ...?
Do you (or anyone else reading this for that matter) have any insight on how gmail -> imap works with labels when a single message has multiple labels? For example an email may be tagged with "clients" "$JOBNAME" and "receipt". Does it put multiple copies of the message in the local cache, or does it do a hard link, or ...?
Gmail's IMAP is unfortunately broken; they implement labels as folders, not tags. This means that the same message in "All Mail", "Inbox", and "Notifications" are three different messages that happen to have the exact same content and almost identical headers/metadata.
So, by default, you're going to be storing multiple copies of each message. It's not a difficult task to use hardlinks instead if you want, but mutt can't make this judgement by itself, because not all of the metadata is identical, and mutt is designed for the general case, not specifically for Gmail.
Note that this is a Gmail issue, not strictly a mutt issue; other IMAP providers don't all have this awkward behavior.
So, by default, you're going to be storing multiple copies of each message. It's not a difficult task to use hardlinks instead if you want, but mutt can't make this judgement by itself, because not all of the metadata is identical, and mutt is designed for the general case, not specifically for Gmail.
Note that this is a Gmail issue, not strictly a mutt issue; other IMAP providers don't all have this awkward behavior.
Great writeup. Have you checked out mutt-kz[1]? It is a mutt fork with fairly seamless notmuch integration.
[1] https://github.com/karelzak/mutt-kz
[1] https://github.com/karelzak/mutt-kz
I wrote an emacs-based e-mail client "mu4e";
see e.g. http://emacs-fu.blogspot.fi/2012/08/introducing-mu4e-for-ema...
Its user-interface is a bit mutt-influenced, but it's fully query-based and very fast, and of course you can extend it using elisp. A fairly young project, but it's near-fully documented, and the manual has instructions on how to set things up with Gmail.
Its user-interface is a bit mutt-influenced, but it's fully query-based and very fast, and of course you can extend it using elisp. A fairly young project, but it's near-fully documented, and the manual has instructions on how to set things up with Gmail.
I'm going to dive in here and give a huge thumbs up to mu4e. I spent a chunk of time with Gnus and Wanderlust and both feel so much slower. I can't make the switch yet because I'm too lazy to research how to get the multiple mailbox/index configuration I have with mutt (if it's possible?) but hopefully will soon.
Really appreciate the work, djcb.
Really appreciate the work, djcb.
There can be only one database (index) per mu4e/emacs instance, but you can store multiple maildirs in one database though, and there's support for multiple accounts (esp. in the upcoming 0.99; there are some recent ML-threads about this).
How does that play out vs. gnus? I have messed around with gnus a bit but don't feel 100% happy with it.
I've been waiting for this post since you first hinted at it. Looking forward to reading it, thanks.
for those on linux, here's a simple .mailcap that i use:
text/html; w3m -M -T text/html %s
image/*; feh -F %s
application/pdf; okular %s
application/msword; oowriter %s
Rather than using your gmail password with offlinemap, albeit protected by keychain, I suggest creating an application specific password for offlinemap. See
http://support.google.com/accounts/bin/answer.py?answer=1858.... This is actually required if you switch to two factor authentication and still want various apps to access your google data.
Steve, I was just looking at Mutt this weekend. Thank you so much for this blog post. It will give me the push to just go and do it. Learn in the process too. How can one say no to that?
I have spent hours and hours configuring my `mutt`, `offlineimap`, `putmail.py`, but I have since grown disenchanted. In my experience, `offlineimap` is annoyingly prone to crashing without any indication. Thus, checking mail within `mutt` becomes unreliable. However, my favorite aspect of `mutt` has been and remains being able to send e-mails very quickly and easily through Terminal.
echo "Hello World!" | mutt -s "Test E-mail" -a "file.txt" [email protected]
If you don't like offlineimap, why not run a true imap server instead? At home I have set up Dovecot + Postfix. I pull in all my remote mail through fetchmail and dump it into my own imap server. Works like a charm and it's not hard to set up.
I use Thunderbird + Muttator for reading from my laptop and mutt through SSH when reading from e.g. work. I can even read it from my Android phone and tablet.
I use Thunderbird + Muttator for reading from my laptop and mutt through SSH when reading from e.g. work. I can even read it from my Android phone and tablet.
Worse than that, offlineimap can be plain destructive in the right circumstances. I've had it arbitrarily delete thousands of messages due to the local cache being in a strange state.
You might try a similar program, mbsync (http://isync.sourceforge.net/). It's worked well for me during the past half-dozen years.
mbsync does not watch or poll for changes, but you can run mbsync in a loop from your shell. Or, if you are running Linux on the mail server and client and use Maildirs, you can run mbsync from mswatch (http://mswatch.sourceforge.net/). (Disclaimer: I'm the author of mswatch.)
mbsync does not watch or poll for changes, but you can run mbsync in a loop from your shell. Or, if you are running Linux on the mail server and client and use Maildirs, you can run mbsync from mswatch (http://mswatch.sourceforge.net/). (Disclaimer: I'm the author of mswatch.)
may i suggest mu http://www.djcbsoftware.nl/code/mu/ for indexing?
i use it with these macros
macro index <F8> "<shell-escape>mu find --clearlinks --format=links --linksdir=~/Mail/search " \ "mu find"
macro index <F9> "<change-folder-readonly>~/Mail/search<return>" \ "mu find results"
i use it with these macros
macro index <F8> "<shell-escape>mu find --clearlinks --format=links --linksdir=~/Mail/search " \ "mu find"
macro index <F9> "<change-folder-readonly>~/Mail/search<return>" \ "mu find results"
This is a great post about a very finely tuned Mutt setup. I always enjoy reading about high customized environments. I am someone who would love to use Mutt but I get so much HTML only email it's sadly impossible for me to do so. (Newsletters and misc friends who think large HTML footers are cool.)
In your .muttrc:
auto_view text/html alternative_order text/plain text text/html
That presents plain text first if it's multiply-encoded, but makes html available. In your mailcap:
text/html; /path/to/browser '%s'; description=HTML Text; test=test -n "$DISPLAY"; nametemplate=%s.html
displays HTML in a browser window for you. mutt launches this when you choose to look at the html version.
But instead, your mailcap could have this:
text/html; lynx -dump %s; copiousoutput; nametemplate=%s.html
which mutt interprets as "filter this through lynx and display it in the terminal" which will solve 98% of your issues. It's fast, too.
auto_view text/html alternative_order text/plain text text/html
That presents plain text first if it's multiply-encoded, but makes html available. In your mailcap:
text/html; /path/to/browser '%s'; description=HTML Text; test=test -n "$DISPLAY"; nametemplate=%s.html
displays HTML in a browser window for you. mutt launches this when you choose to look at the html version.
But instead, your mailcap could have this:
text/html; lynx -dump %s; copiousoutput; nametemplate=%s.html
which mutt interprets as "filter this through lynx and display it in the terminal" which will solve 98% of your issues. It's fast, too.
I'll give lynx a try with this, I can't use a full browser as it would be on a remote computer setup. Thanks for the tip!
Super awesome! I use mutt on a remote server and don't want a browser involved. This recipe really does a nice job.
What are the advantages of using gmail as your server rather than, say, installing your own postfix server on some linode?
Gmail has largely solved the spam problem. Configuring spam filters and the like is still a PITA with your own server.
Yep, collabrorative filtering works very well. It's very rare I have spam in my Gmail inbox.
I think the very idea of pitching mutt to Sparrow target audience is brilliant. Getting out of your comfort zone may be gainful :)
> Now that Sparrow is effectively dead
Sparrow 1.6.4 was released on September 11, 2012. Mutt 1.5.21 was released on September 15, 2010.
You keep using that word. I don't think it means what you think it means.
Sparrow 1.6.4 was released on September 11, 2012. Mutt 1.5.21 was released on September 15, 2010.
You keep using that word. I don't think it means what you think it means.
As when Knuth stopped releasing new versions of TeX because it reached a point where it was "done", software that has been around for long enough can eventually mature to the point where there's nothing left to add without expanding the scope of the project beyond its original definition.
Mutt may simply be at that point. I use Mutt as my primary MUA in a very similar manner to the author of the article, and I can't really say that there are any features that I want that it lacks. Of course, I can't speak for everyone on that point; for instance, some people actually want to send and receive HTML email, and Mutt can't easily deal with that. But for some of us, lack of HTML support is itself a feature, and when you really have to, piping a text/html MIME part to a browser for rendering is really easy to accomplish.
I know essentially nothing about Sparrow, but I suspect that it is a much newer product than Mutt, has had far less time to mature, and as such simply requires a more frequent release schedule than a project with Mutt's long history.
Basically, a comparison between most recent release dates doesn't necessarily mean what you think it means.
Mutt may simply be at that point. I use Mutt as my primary MUA in a very similar manner to the author of the article, and I can't really say that there are any features that I want that it lacks. Of course, I can't speak for everyone on that point; for instance, some people actually want to send and receive HTML email, and Mutt can't easily deal with that. But for some of us, lack of HTML support is itself a feature, and when you really have to, piping a text/html MIME part to a browser for rendering is really easy to accomplish.
I know essentially nothing about Sparrow, but I suspect that it is a much newer product than Mutt, has had far less time to mature, and as such simply requires a more frequent release schedule than a project with Mutt's long history.
Basically, a comparison between most recent release dates doesn't necessarily mean what you think it means.
I knew if I made this joke I'd get a wall of text explaining why I was wrong; thanks, HN — you delivered!
On a more serious note, I use Sparrow every day. About the only quibble I have with it is some of the icons aren't retina versions (hardly a dealbreaker). Otherwise I'd say it meets my needs very well; doesn't that also make it ‘done’, rather than ‘effectively dead’?
On a more serious note, I use Sparrow every day. About the only quibble I have with it is some of the icons aren't retina versions (hardly a dealbreaker). Otherwise I'd say it meets my needs very well; doesn't that also make it ‘done’, rather than ‘effectively dead’?
Mutt has plenty of unfixed bugs, just look at the bug tracker and distro-specific patches (in Debian for instance). It is a wonderful piece of software, I use it daily, but its development definitely miss momentum.
Tried mutt, but I never really liked.
Nowadays I use 'Sup, but I might go (back) to Alpine, because its best feature - the indexer - is also its major drawback, since it hits the disk pretty heavily, which my VPS providers don't care for.
Nowadays I use 'Sup, but I might go (back) to Alpine, because its best feature - the indexer - is also its major drawback, since it hits the disk pretty heavily, which my VPS providers don't care for.
Sparrow is still getting small updates on both iOS and OS X. Mutt hasn't been updated in a few years. I'm not sure one is more dead than the other.
Also, one app became loved because it has a really innovative UI and the other is an app that eschews a modern UI. I'm not sure many people will logically make the leap from Sparrow to Mutt. More likely, people will gravitate back to to gmail.com, which should be getting a lot of improvements from the Sparrow team in the future.
Also, one app became loved because it has a really innovative UI and the other is an app that eschews a modern UI. I'm not sure many people will logically make the leap from Sparrow to Mutt. More likely, people will gravitate back to to gmail.com, which should be getting a lot of improvements from the Sparrow team in the future.
> Mutt hasn't been updated in a few years
http://dev.mutt.org/hg/mutt/ says two months.
http://dev.mutt.org/hg/mutt/ says two months.
I'm not sure one is more dead than the other.
Mutt is Open Source.
Mutt is Open Source.
[deleted]
"Mutt certainly isn’t the prettiest email client around, and its setup/configuration process is one of the ugliest out there. But once you get it set up it’s got a lot of advantages over many other email clients."
Stopped reading, right there. Why are we still fighting with things that are difficult/ugly to setup/configure? Could have been the best tool ever written, but if I have to spend a half a day figuring it out, and there are other tools that do it better, I'm out.
Stopped reading, right there. Why are we still fighting with things that are difficult/ugly to setup/configure? Could have been the best tool ever written, but if I have to spend a half a day figuring it out, and there are other tools that do it better, I'm out.
"We" (meaning not you, apparently) are still doing that kind of thing because we know we'll spend thousands of days using the tool, so a few hours spend leaning it seems like a bargain. I could just as easily ask why "we" (meaning you) are still getting confused between "discoverability" and "usability" after decades of silly arguments like this.
Don't use mutt, that's fine. But come up with some better justifications. (edit for full disclosure: I don't use mutt either, having to deal professionally with enough unreadable-in-plain-text mail that it makes more sense for me to do everything in Thunderbird.)
Don't use mutt, that's fine. But come up with some better justifications. (edit for full disclosure: I don't use mutt either, having to deal professionally with enough unreadable-in-plain-text mail that it makes more sense for me to do everything in Thunderbird.)
I put time in when I feel like the tool may solve an issue or problem I have and when I think there will be a ROI for the time I spend doing it.
This seems like a pretty reasonable justification to me. Having spent a lot of time authoring emails in different tools, I'm comfortable with what I have. If what I have does what I want and the other tool that people are telling me is better has a disclaimer like the above, then what exactly am I doing wrong?
I'm all for trying out new tools and I spend hours doing so every week. I have to pick and choose what it is that I utilize. I wasn't arguing that the tool might not be valuable for some folks, just that it did a very good job of un-selling me, very quickly.
This seems like a pretty reasonable justification to me. Having spent a lot of time authoring emails in different tools, I'm comfortable with what I have. If what I have does what I want and the other tool that people are telling me is better has a disclaimer like the above, then what exactly am I doing wrong?
I'm all for trying out new tools and I spend hours doing so every week. I have to pick and choose what it is that I utilize. I wasn't arguing that the tool might not be valuable for some folks, just that it did a very good job of un-selling me, very quickly.
Am I supposed to eschew powerful tools because there wasn't a UX guy involved in the project?
If I cared that much about ease of configuration, I'd use Textmate instead of Vim, and Colloquy instead of irssi.
If I cared that much about ease of configuration, I'd use Textmate instead of Vim, and Colloquy instead of irssi.
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 since "September 15, 2010" and hasn't had any commits for two months.
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 since "September 15, 2010" and hasn't had any commits for two months.
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 year old terminal GNU/Unixy programs.
If someone came up with Vim today, with a slick polished GUI interface, etc... you'd find far less people talking about how great it is and you'd find the same people who are appreciating them today, making fun of it.
I know that's a generalisation and doesn't involve everyone but I think it is not insignificant.
There are a minority who use and need the tool and appreciate it for what it is and have been long time users. For every 1 of those people, there are thousands more who simply follow the teachings of the cult to be in the cool nerds club.
There seems to be a pattern here, a recipe for a shitty (once useful) program that is no longer relevant that a group just doesn't want to let it go.
It kinda goes like this,
1. Be a 20-something year old program written by some GNU/Unix kernel/hardcore/early developer
2. Run in terminal with a million options and parameters
3. Be extensible with all sorts of weird text file configs, plugins etc...
4. Have a short weird-sounding name that is an abbreviation of some other weird phrase
That's all you need. Then no matter how terrible the user experience is and how outdated and irrelevant your program has become, you'll always have that cult who religiously love your program and insist on extending it so it can be a space shuttle as well as a text editor and an email client.
I should point out I'm not mocking any application in particular and I think many of these tools were fantastic for their times and some of them are still quite good today but my rant is towards this obsessive religious overly-appreciative culture of praising these softwares.
We are past that age of black screens and terminals and horrible user experiences. They were fine for their times but not anymore. I'm not gonna put up with an application that is almost as old as myself and spend hours to configure it just to be a little more efficient.
The efficiency argument seems more like an excuse, because you don't want to admit that you are putting up with the downsides of the application because of all other nerd-culture reasons.
</rant>
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 year old terminal GNU/Unixy programs.
If someone came up with Vim today, with a slick polished GUI interface, etc... you'd find far less people talking about how great it is and you'd find the same people who are appreciating them today, making fun of it.
I know that's a generalisation and doesn't involve everyone but I think it is not insignificant.
There are a minority who use and need the tool and appreciate it for what it is and have been long time users. For every 1 of those people, there are thousands more who simply follow the teachings of the cult to be in the cool nerds club.
There seems to be a pattern here, a recipe for a shitty (once useful) program that is no longer relevant that a group just doesn't want to let it go.
It kinda goes like this,
1. Be a 20-something year old program written by some GNU/Unix kernel/hardcore/early developer
2. Run in terminal with a million options and parameters
3. Be extensible with all sorts of weird text file configs, plugins etc...
4. Have a short weird-sounding name that is an abbreviation of some other weird phrase
That's all you need. Then no matter how terrible the user experience is and how outdated and irrelevant your program has become, you'll always have that cult who religiously love your program and insist on extending it so it can be a space shuttle as well as a text editor and an email client.
I should point out I'm not mocking any application in particular and I think many of these tools were fantastic for their times and some of them are still quite good today but my rant is towards this obsessive religious overly-appreciative culture of praising these softwares.
We are past that age of black screens and terminals and horrible user experiences. They were fine for their times but not anymore. I'm not gonna put up with an application that is almost as old as myself and spend hours to configure it just to be a little more efficient.
The efficiency argument seems more like an excuse, because you don't want to admit that you are putting up with the downsides of the application because of all other nerd-culture reasons.
</rant>
Or, perhaps, the tools do something well, are flexible in their approach, and, by way of incremental improvements and configurations over time, fit very hand-in-glove with those who've been using them for some time.
I'd used multiple email programs before finding my way to mutt, including various GUI programs. I'd used elm and pine briefly and somewhat enjoyed them. My primary mailer prior to mutt was Netscape's built-in mail client (NN3/4). The main problems with that were instability and some lack of flexibility.
Mutt took a week or so of getting used to ... and then ... just worked.
Not having an integrated editor (e.g.: making use of vim) was a huge win. One of the huge benefits of console-mode tools is that they can make use of one another in this way.
I've used a great many email clients since encountering mutt, and none are as fast, effective, reliable, and efficient as mutt. I keep coming back.
My complaints? Search through large volumes of mail (10s to 100s of thousands of messages) is slow. Google's use of tags is really useful, and more flexible than a highly-structured set of mailboxes. There are add-ons / forks of mutt which provide both features.
There's also a lot to be said for tools which work over a minimal configuration -- 24x80 vt100 emulation over serial line (your "last ditch" remote access method for most servers), SSH, Connectbot, console, etc.
Knock them all you want. The tools are useful, ubiquitous, standard, and effective.
I'd used multiple email programs before finding my way to mutt, including various GUI programs. I'd used elm and pine briefly and somewhat enjoyed them. My primary mailer prior to mutt was Netscape's built-in mail client (NN3/4). The main problems with that were instability and some lack of flexibility.
Mutt took a week or so of getting used to ... and then ... just worked.
Not having an integrated editor (e.g.: making use of vim) was a huge win. One of the huge benefits of console-mode tools is that they can make use of one another in this way.
I've used a great many email clients since encountering mutt, and none are as fast, effective, reliable, and efficient as mutt. I keep coming back.
My complaints? Search through large volumes of mail (10s to 100s of thousands of messages) is slow. Google's use of tags is really useful, and more flexible than a highly-structured set of mailboxes. There are add-ons / forks of mutt which provide both features.
There's also a lot to be said for tools which work over a minimal configuration -- 24x80 vt100 emulation over serial line (your "last ditch" remote access method for most servers), SSH, Connectbot, console, etc.
Knock them all you want. The tools are useful, ubiquitous, standard, and effective.
Add in that they run it from a Mac and I'm on-board with you.
lol.
lol.
Valid point and I fall into this camp for all sorts of key software (e.g. you'd never catch me spending more than 5 mins tweaking a new web browser).
For other software, e.g. my editor, my mail client - software i'm producing content in, rather than consuming, i'll happily put in a few hours up front to get comfortable on the grounds that i will reap a greater reward in time saved medium term.
For other software, e.g. my editor, my mail client - software i'm producing content in, rather than consuming, i'll happily put in a few hours up front to get comfortable on the grounds that i will reap a greater reward in time saved medium term.
If I could have seen that there would have been some value outside of what I currently use, I'd totally look into it. I too am more likely to spend some time messing around with editors, IDEs and other tools than I am email clients though.
Something difficult to set up and/or configure can still be worth the suffering. Sure, it'd be great if it was easy to configure to boot, but sometimes pain now can reap greater payback down the line...
This may be stretching the applicable domain a bit, but I think the concept of YAGNI applies to the time/effort spent on configuring primitive tools to suit use cases that -may- present themselves in the future.
i agree, that seems like a huge pain in the ass to configure when sparrow is working fine for me.
I switched back to Mutt a few months ago after trying Mail.app (filtering wasn't up to my requirements, would hang often) and Thunderbird (bloated and slow under load). It's been a champion.
urlview.sh is pretty awful, mis-parsing urls constantly for me. I then discovered extract_url.pl[1], which is much, much better.
offlineimap likes to hang randomly - mail just stops coming in and the process never stops, requiring me to remove the lockfile by hand, then kill the process. I haven't found a replacement for it, unfortunately. Definitely open to suggestions on this front.
The linked view_attachment.sh file has problems, for example, with files with multiple dots in the filename (among others). I have made a few tweaks[2] to it to make it more robust. It still has a few issues, but I've found it to work better for the most part.
msmtp is probably unnecessary nowadays if you have a typical setup. For GMail, add the lines:
I also wrote a very small, crappy applescript launcher to launch an iTerm with mutt from the OSX dock[3]. It won't open a second copy if already running, but I haven't been able to figure out how to display a badge on the dock to denote unread mail. It may not be possible.
[1] http://www.memoryhole.net/~kyle/extract_url/
[2] https://github.com/xxx/dotfiles/blob/master/osx/mailcap/view...
[3] https://github.com/xxx/dotfiles/blob/master/osx/mutt/mutt-it...
urlview.sh is pretty awful, mis-parsing urls constantly for me. I then discovered extract_url.pl[1], which is much, much better.
offlineimap likes to hang randomly - mail just stops coming in and the process never stops, requiring me to remove the lockfile by hand, then kill the process. I haven't found a replacement for it, unfortunately. Definitely open to suggestions on this front.
The linked view_attachment.sh file has problems, for example, with files with multiple dots in the filename (among others). I have made a few tweaks[2] to it to make it more robust. It still has a few issues, but I've found it to work better for the most part.
msmtp is probably unnecessary nowadays if you have a typical setup. For GMail, add the lines:
set smtp_url = smtp://[email protected]@smtp.gmail.com:587/
set smtp_pass = mah_password
I also wrote a very small, crappy applescript launcher to launch an iTerm with mutt from the OSX dock[3]. It won't open a second copy if already running, but I haven't been able to figure out how to display a badge on the dock to denote unread mail. It may not be possible.
[1] http://www.memoryhole.net/~kyle/extract_url/
[2] https://github.com/xxx/dotfiles/blob/master/osx/mailcap/view...
[3] https://github.com/xxx/dotfiles/blob/master/osx/mutt/mutt-it...
I had the same problems with Offlineimap while running it as a long-lived background process, and wasn't able to find any clean way to resolve them.
Nowadays I have a cron script that kills any existing Offlineimap processes, and allows a new one to run through once. Works perfectly.
Nowadays I have a cron script that kills any existing Offlineimap processes, and allows a new one to run through once. Works perfectly.
Try isync. I had some crashes with 1.0.4 but 1.0.5 has been working well: http://isync.sourceforge.net/
I do almost exactly the same thing except I use getmail as my MRU and I have it checking many different email accounts (gmail, work mail, other work mail, etc). mutt is the best email client I've ever used. I like taking control of my email, using my own paid-for smtp service (tuffmail) and in general not relying on hosted email providers. procmail or maildrop are very handy too.
There's one and only one reason that I haven't ever switched to a terminal based email client.. HTML messages. I want to see images and formatted text, not an unholy mess of tags and other detritus the program can't render.
As much as I like Alpine, being stuck on the terminal is a total deal breaker. It's 2012 ferchrissakes - why are we using email tech that's stuck in the 80s? Why does "modern" have to be at constant odds with "simple and functional"?
As much as I like Alpine, being stuck on the terminal is a total deal breaker. It's 2012 ferchrissakes - why are we using email tech that's stuck in the 80s? Why does "modern" have to be at constant odds with "simple and functional"?
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.
MIME html emails should have a plain text part that will be display properly and should contain essentially the same content.
One or both of those fail often enough that I have mutt set to display the HTML part, using w3m to render it as text.
One or both of those fail often enough that I have mutt set to display the HTML part, using w3m to render it as text.
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?
We've got this wonderful invention called the graphical user interface.. why not leverage it?
There's an unexamined assumption underlying your comments: Namely that because something is terminal-based, it's 'not modern', and that the GUI unambiguously represents progress on all fronts for all uses.
But consider: in the 30 odd years of GUI prevalence, there has never been an example of a GUI email client as simple (for some value of simple), functional, and powerful-for-power-users, as Mutt and Pine.
I think it's at least worth considering the possibility that you're asking for is the equivalent of wondering why you can't just have a lighter-than-air balloon made out of lead; the possibility that GUIs might represent progress along some axes (discoverability and approachability) while fundamentally constraining you along others (power, functionality).
But consider: in the 30 odd years of GUI prevalence, there has never been an example of a GUI email client as simple (for some value of simple), functional, and powerful-for-power-users, as Mutt and Pine.
I think it's at least worth considering the possibility that you're asking for is the equivalent of wondering why you can't just have a lighter-than-air balloon made out of lead; the possibility that GUIs might represent progress along some axes (discoverability and approachability) while fundamentally constraining you along others (power, functionality).
>But consider: in the 30 odd years of GUI prevalence, there has never been an example of a GUI email client as simple (for some value of simple), functional, and powerful-for-power-users, as Mutt and Pine.
That's exactly my point though - why do most email clients suck so bad? Slow and bloated are the most common adjectives thrown around (Outlook, Thunderbird), and if not that, then there's the weird UI's (Eudora, The Bat) - and then there's the terminal clients, while very nice, very fast, very functional, completely ignore all progress made in user interfaces over the past 20 years. (Pine, Mutt)
It's like you have a choice: Modern, Fast, Functional. Pick any two.
This is something I can imagine coding . Give me something like Pine or Mutt that works in a GUI and can render HTML and images, but still "looks" and runs like Pine or Mutt. Imagine it in your head for a moment - the same UI, but instead of html strewn about everywhere, you have actual rendering of html and images (via choose-your-favorite engine, leaning towards Webkit) in the same window.
I don't think that HTML rendering, speed, and functionality are mutually exclusive goals.
That's exactly my point though - why do most email clients suck so bad? Slow and bloated are the most common adjectives thrown around (Outlook, Thunderbird), and if not that, then there's the weird UI's (Eudora, The Bat) - and then there's the terminal clients, while very nice, very fast, very functional, completely ignore all progress made in user interfaces over the past 20 years. (Pine, Mutt)
It's like you have a choice: Modern, Fast, Functional. Pick any two.
This is something I can imagine coding . Give me something like Pine or Mutt that works in a GUI and can render HTML and images, but still "looks" and runs like Pine or Mutt. Imagine it in your head for a moment - the same UI, but instead of html strewn about everywhere, you have actual rendering of html and images (via choose-your-favorite engine, leaning towards Webkit) in the same window.
I don't think that HTML rendering, speed, and functionality are mutually exclusive goals.
I use alpine and have set w3m as the HTML reader in my mailcap file. w3m also displays images in HTML. Alpine is able to display most HTML emails just fine, but when it fails, I simply press V (which shows different mime parts of the message) and Enter (by default the focus is on the 2nd part, which is text/html; Enter launches the default html browser, which is w3m that displays the message). This gives all the benefits of alpine, with the option to display html+images in the same terminal if I need to.
> 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!!
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!!
Recent versions of Exchange strip off the plain text part as a default.
Your company's IT staff probably can't be arsed to change the default, if you can so easily change your email client instead.
Your company's IT staff probably can't be arsed to change the default, if you can so easily change your email client instead.
I use Alpine precisely because it's text based and email is text. Alpine fits the task perfectly and it's quick to command with its keyboard shortcuts. Things make more sense this way and everything stays within its own appropriate scope.
For HTML emails I have configured a "printer" in Alpine that unpacks the HTML part and all relevant images and attachments and writes them to disk, finally launching my web browser to show the HTML file. But I generally just view the HTML email through Alpine's own text conversion and only fire up the full version if the email has important-looking images such as graphs. Mostly the images are just header/footer logos and stuff like that, I don't need them.
For HTML emails I have configured a "printer" in Alpine that unpacks the HTML part and all relevant images and attachments and writes them to disk, finally launching my web browser to show the HTML file. But I generally just view the HTML email through Alpine's own text conversion and only fire up the full version if the email has important-looking images such as graphs. Mostly the images are just header/footer logos and stuff like that, I don't need them.
[deleted]
I love mutt! Unfortunately, I often write emails while looking at another one, which I couldn't make work with mutt. Any ideas?
You could use a terminal multiplexer (tmux, screen, etc) to just split-screen your terminal.
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'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?
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.
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.
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.
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.
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:
You can even pipe output straight to mutt:
df ¦ mutt -s "disk utilization" [email protected]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:
In practice, I generally run mutt within screen, with multiple frequently-accessed mailboxes open. I switch mailboxes by moving between screen buffers.
mutt -Rf <mailbox name>
In practice, I generally run mutt within screen, with multiple frequently-accessed mailboxes open. I switch mailboxes by moving between screen buffers.
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.
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/
[1]http://lee-phillips.org/muttheaven/
I like nmh, myself.
How-to article?
http://rand-mh.sourceforge.net/book/
Jerry Peek's MH book, free to read. How-to times ten.
Jerry Peek's MH book, free to read. How-to times ten.
[deleted]
I should.