Mutt 1.6
mutt.org
mutt.org
It was 2003 and I was a dedicated and exclusive Mutt user (this, before Gmail came along).
Due to some accidental press of the wrong key combination, somehow Mutt managed to take every single email in my Sent folder and combine it into one gigantic aggregate text document -- a record of all emails I'd ever sent from that account -- and turn this aggregate itself into an outgoing email, ready for sending.
What's worse, it took every address that had ever been in a To: field in any Sent mail and put them all as one big list in this aggregate email's To field!
With just one more keypress, had I accidentally then sent this, every person I'd ever emailed would have received a copy of every email to any person I'd ever sent.
Can you imagine the disaster? That I could concoct such an email accidentally was terribly frightening and that was the last year I ever used Mutt.
T.<cr>;g
I would not characterize this as a single command...
Marissa Mayer prefers Pine to Gmail
[mayer]Marissa Mayer, VP, Search Products and User Experience at Google confesses to CNN Money that she doesn't use Gmail for her business mail.
"I don't feel overwhelmed with information. I really like it. I use Gmail for my personal e-mail -- 15 to 20 e-mails a day -- but on my work e-mail I get as many as 700 to 800 a day, so I need something really fast. I use an e-mail application called Pine, a Linux-based utility I started using in college. It's a very simple text-based mailer in a crunchy little terminal window with Courier fonts. I do marathon e-mail catch-up sessions, sometimes on a Saturday or Sunday. I'll just sit down and do e-mail for ten to 14 hours straight."
Pine is a mail program developed at the University of Washington. It has a lot of keyboard shortcuts and countless ways to sort, shuffle, and sift through your email.
http://dealbook.nytimes.com/2012/07/27/adding-up-marissa-may...
Urgent mail is expedited at his secretary's discretion, of course.
(Yes, I know she's also phenomenally successful, but so are MANY more people that don't share her methods)
Not this guy, who worked at Google from the start:
http://www.amazon.com/Im-Feeling-Lucky-Confessions-Employee-...
From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [git pull][resend] Input updates for 2.6.22-rc7
Date: Fri, 06 Jul 2007 01:11:27 UTC
Message-ID: <fa.IgmANxZoEvqGUWkoZEe414vIYlQ@ifi.uio.no>
On Fri, 6 Jul 2007, Jesper Juhl wrote:
>
> > I'm constantly surprised by just how _many_ ways MUA's find to screw up.
>
> 'pine' actually seems to work pretty damn well once you disable the
> flowed-text "feature".
Yes. And 'alpine', it's modern version, does even better, but you also
need to make sure to disable "downgrade-multipart-to-text".
I've been using alpine for a while now, and it's nice to see it be utf-8
capable and able to handle other charsets well.
So as a former pine user, I can recommend upgrading.
LinusIntegration with other utilities (notmuch, isync) for indexing and sync'ing is very easy, thanks to close adherence to Unix principles, and gets you a very neat setup. Nothing to envy from Gmail.
What do you use for mobile access?
An android phablet with a full hardware keyboard.
Some decent pictures: http://pandoralive.info/?p=5519
I switched because of search, which is amazing in gmail and hard in mutt (for me). What do you do?
really? until a few months ago, you couldn't find anything besides whole words with textual search on gmail. why do people have it's search at such high standards? how bad was the alternative you had?
Since someone may ask, my desires are simple in nature, but i'm sure difficult to implement. I simply want to find an email. On the Google Search side of things, i have often been very impressed by the search results i am able to achieve. Yet for email, it's been far less successful.
On Search, i'm able to use synonyms, or hell even vaguely describe (in the case of movies) plots, and often be presented with what i want. On Gmail, it feels like Gmail has no idea about the context or content of my mail (which is arguably their selling point), and instead i'm purely searching by keyword. The frustration is amplified by the fact that Search(proper) works so surprisingly well, i'm sure.
Senders name or email? That has always been an option. Has attachments? Been an option since forever. tags? Since forever. date? Available since forever.
For reference, you used to be able to do this - https://code.google.com/p/chromium/codesearch - with an archived cross-section of code on the Web.
I wonder if we'll ever be able to do regex Google searches in the future, or if AI/machine learning will make that sort of flexibility redundant by the time the hardware would be able to handle it.
But seriously, all these hard core unix fans seem a little odd here. Gmail search has always been powerful, and is even more powerful now. It sounds like a case of user error if it isn't working for someone.
Suppose, for example, I have set up a subdir for conferences. That subdir contains a bunch of subdirectories for individual conferences. I know the e-mail I'm looking for is stored in there, because it relates to a conference publication I wrote. However, that subdir itself is "empty" as far as gmail search is concerned (because it's a "tag" rather than a true subdirectory).
The net effect of these hollow imitations of directories is I can either target the search to a specific tag, or I can search throughout my entire collection of messages. (Or, I suppose, I can tag every e-mail with every single sub-tag represented in the directory hierarchy I have mentally set up, just in case I might want to search for it someday.)
The gmail ideal, of course, is that I abandon the notion of directories altogether, and just let all my messages stew in the ocean of e-mail that one accumulates over the years. Supposedly their "powerful" search capabilities will help me find what I want. In my experience, though, under this approach most reasonable searches produce multiple pages of possible matches. This, of course, is hardly efficient.
It would also be nice if I could perform a search and then pull out that page of returned results into a separate screen/window for ongoing reference. Often when I'm searching for something, I'm looking broadly for resources or related conversations, rather than for a specific message.
Another place where I feel gmail search is brain-dead is its lack of regex capability (which @devdas has already mentioned).
Separate screen of search results is just another tab in your browser - that's actually a vote in favor of web based gmail.
To make my example explicit above, suppose I have a "directory" structure with dirs like `conf`, `conf/iaq2016`, and `conf/gmu2012`. Then a search in `conf` will not turn up results in `conf/iaq2016` or `conf/gmu2012`.
Believe me, I check this once every few months, always hoping that google will have improved their "tag" implementation.
I do appreciate your tip about multiple browser windows, though. In general, I don't like having multiple windows open to the same application-- but that's my problem, and not a design flaw in Gmail's search.
I'm curious, what other search does one do in email?
There's also mutt-kz, with notmuch deeply integrated.
zcat Mail/2015/mbox.gz | grepmail -i whatever | grepmail 'perl.style.*regex' >myresults
mutt -f myresults
Emacs has always been That Way. And then CERN/Mosaic happened, and browsers (being all-singing, all-dancing environments that do everything from page layout to hosting interpreters and databases, are also big apps) came along.
This has not lead to awk becoming an MUA, or tmux adding a flight simulator, or tee offering to store things as PDFs. Nor has it stopped the development of building-block tools - I still see more nifty new things built with more or less the same assumptions than I can play with.
The only thing I can think of is that you're referring to GUI apps, at least mostly on Linux. GUIs (or more specifically, what Alan Cooper termed 'sovereign applications', but they are mostly GUIs) are typically subject to Zawinski's Law in ways that command line tools are not. Heck, Mutt is somewhat subject to it, itself, for that reason.
<Hoping no-one runs "w" while I'm in elinks>
Its a nice little useful heuristic or reminder to ask yourself if maybe what you are doing is too much.
But maybe what you are doing isn't too much.
That's all it should ever be, IMHO... a reminder to check yourself at some point or another - but its perfectly valid to conclude that your monolithic, large app can and does many things well, and cohesively adds something of value to the software world, that can't or hasn't been accomplished by tiny composable bits, or at least not nearly as well.
I'm certainly not saying that it is the way to go, but a real Unix philosophy way of dealing with email would be to use a command to pull mails from a mail server as text files (heck, as a text stream!), then other commands to display them, sort them, ...
I use mbsync to synchronize my mail over IMAP with my remote mailserver. I use mu to index it for search. I use msmtp to send mail. And I use mutt to read and write mail.
That is, it just reads emails on a local mailfolder. Fetching emails to that mailfolder from the server, sending emails and doing other operations is a task of 3rd party programs.
[1] OK, it has a few addons for lazy people. But most experienced users ignore them.
I don't think that mutt is the most unix-philosophy-aligned MUA possible, it feels kind of like GNU tools: unixy, but jam packed with too many flags and options and convenience features. The unix philosophy would prefer that the application's design be changed to better accomodate implementing those extra features externally where plausible. But the perfect unix MUA would do the same things as mutt.
In my opinion this concept does not work for most non-cli programs. How do you actually define this "one thing"?
Is "reading an email" one thing? And "writing an email" another thing? What about "spellchecking the email"? What about "managing all my email contacts"? What about "back up my emails"? What about "sign email with GPG"?
Do all of these things really need a separate program?
The unix principle works quite well for stuff like grep/find/awk but there is just now way you could make GIMP follow the unix principle.
That is, I have no problem with being able to read, write, spellcheck, and sign an e-mail, manage my contacts, and back up my archive from within a single program; but it had better be true that, if I want to use vi instead of Nano to write my e-mails, then I can force the program to respect this wish.
(As is probably apparent, I'm a Pine user by experience; I've never used Mutt, but would like to give it a try.)
Mostly everything else is outsourced. Composing is done by your $EDITOR, sending is done by an external program, fetching email by an external program too. Even indexing and querying is usually outsourced to a modern xapian-based tool, like mu or notmuch.
This leads to powerful composable workflows.
;)
Need to convert 10, or 100, or 1,000, or 1,000,000 images? You might use GIMP for the first. You'd best give it up for the 2nd and further.
On Linux desktop, I had an Imagemagick command in my command history which would trim off the top n pixels of images to remove extraneous elements. Quick to call that up and run it on a new screenshot, or a series of shots, prior to posting online. The job was completed before GIMP would finish initialising.
So can the Gimp. I wrote a calendar script in Perl for the Gimp literally 15 years ago.
Imagemagick though makes simple-to-moderately-complex stuff bog easy.
Indeed. This is one of the reasons why the unixy "One app does one thing" philosophers dislike the C++ language so much. C++ is built for creating precisely the kind of apps you are describing - Classes are a well-defined compartment or component that does this "one thing" business while the app co-ordinates their working towards a common good.
C, on the other hand, pertains much to their "one thing" philosophy and they like it very much.
That's essentially what Mutt does. But you could also use other programs to parse and read each email file if you wish. "Fetching email" can also be a different thing. I use offlineimap for that purpose and store my messages in the Maildir format.
> And "writing an email" another thing?
Yes. Even "sending an email" is another thing. The program that edits my emails (vim) is not the same program which sends them (msmtp).
> What about "spellchecking the email"?
I don't do this (with a program), but I assume you could just do it within Vim.
> What about "managing all my email contacts"?
I use OS X Contacts for that, so there's a command-line tool that allows me to search for and then insert those contacts in Mutt.
> What about "back up my emails"?
Again, another program! I keep my Maildir synchronized to my home server and all my other computers using BitTorrent Sync. Changes are backed up with Arq to Amazon Glacier every day.
> What about "sign email with GPG"?
Definitely its own program, although Mutt includes support for it you still need GPG installed and everything set up for that stuff in order to sign your emails. This is true for every other email client isn't it? I know I have to instal GPGMail to get the same functionality on Apple Mail.
So you see, all of these tools are really separate processes in and of themselves. The benefit to all of this is when newer and better technology comes around, you don't have to wait for your software vendor to support it. Instead, you just use a different program that follows the same standards, which have been around for decades. Some people, probably most, find this to be an unacceptable burden. For that, there are definitely great email clients out there like Nylas N1 and Google Inbox...but if you want total control in the same sense that you get from your shell and your editor, Mutt is the client for you.
But no mention of OS X contacts integration. Care to share how you do it?
I don't see how CLI programs avoid this. "One thing" is a human idea, subject to interpretation. Should grep and sed be consolidated? Does find do too much? Why do we have both echo and printf?
> Is "reading an email" one thing? And "writing an email" another thing?
Mutt says so. You read and sort emails in Mutt, you write emails in $EDITOR and then you can add attachments and such back in mutt.
> What about "spellchecking the email"?
Well since mutt outsources writing the email, I can't really comment on what mutt does. But if you don't want to do spellchecking within your editor for whatever reason, mutt lets you pipe the contents of anything to an external program, so you could write your email, then select the message from the attachments list and type "|aspell -a<CR>" and you'll get a basic spellcheck.
> What about "managing all my email contacts"?
I think that's pretty clearly a seperate program's duty, since contacts are used by other applications as well. Not only does mutt agree with me, so do Google and Apple. Mutt makes it simple to integrate with external contact lists to provide autocomplete for known email addresses.
> What about "back up my emails"?
That should be taken care of by both your email provider and your personal backup solution. I don't see why an email client would care about backups.
> What about "sign email with GPG"?
Well that's a job for GPG isn't it? That again can be accomplished by just piping the message into an external command. If you use it frequently you'd write some config and scripts to automate it. I saddly rarely uses PGP for email so I don't have hands on experience with this, but it looks like mutt has built in support for this kind of automation. A more unix-aligned approach would be to ship an /usr/share/mutt/examples/auto-gpg.muttrc or something like that that users can just source in their config files.
> but there is just now way you could make GIMP follow the unix principle.
No? Represent layers as a bunch of image files in a directory. Have one program check when they change and composite them in realtime. Have another program render the output of that one to the screen. Have a third integrate with the rendering program and manage the creation of selections (represented as a selection mask, so it supports everything from rectangular selection to brush selection). Drawing tools and filters become programs that take an image and a selection and some (interactive) options and output a new image. Then you have a UI program that brings all these programs together.
If this isn't as performant as Gimp, you can optimize it, for example, by replacing pipelines between parts of the standard toolchain with some kind of shared memory IPC or something similar.
It's not that the ideas behind unix don't apply to modern software; people just don't give a fuck.
Being just a little bit hard-arsed about these things can pay off dramatically.
There was a suite of programs that worked that way: https://en.wikipedia.org/wiki/MH_Message_Handling_System
http://rand-mh.sourceforge.net/book/mh/shomes.html#WeOBeYRe
Using MIME or GPG required a little configuration (mostly preset properly) which hooked external programs to preprocess before sending or displaying the message.
In fact, sometimes it can be the "only" thing you want. Most often it is the case with open source developers when they want to catch up a huge discussion thread. (Like bugs to email interface). Mutt is excellent here.
If I have something to add to the discussion, I have the option to use the command line or log in to web interface and post my response.
It seems that the unix principle is most relevant when compiling a C program takes too long and no interpreters exist that are fast enough. So, you figure out all the higher level functionality that you will need for system administration and compile that long before needing to do any sysadmin work. When a problem arises on a system, you can write a shell script that uses those already compiled commands, instead of writing a C program and waiting for it to compile. If your initial code sucks, you don't have to debug and recompile; you just debug and re-run the script.
Compiling C programs is now substantially less time consuming, so you could use C for sysadmin work (shudder). C shell was perhaps a similar attempt to get the benefits of C, but without the downside of compilation times. I seem to recall some essay on the harmfulness of using csh, so C will continue to keep its place.
I think my dissatisfaction with mutt + rss2email is more about RSS in general. It amounts to just being a short description of the article and a hyperlink, and at that point I might as well just load these websites in my browser.
I need a better article scraper. General solutions that try to detect content, like Firefox's article mode and similar, don't do enough.
We need youtube-dl for text.
I can't but help feeling though these days it just doesn't really gain you anything substantive to bother to learn it, or even continue to use it, and spend the hours it will require to dial in and maintain your configuration.
Most gui clients are good enough.. webmail (Gmail and alternatives) are good enough, unless you have some non-negotiable requirement that mandates you have your own self-hosted email servers, I have a hard time believing its not an overall productivity loss to spend time in mutt (or Gnus for emacs, and other such things).
If you like to tinker with that kind of thing, and you like making your email client a hobby of sorts, cool. But what do you really gain other than a techno-bauble to tinker with?
This is my main gripe with mutt. The days where I could futz around with 100 config setting for hours are long behind me. Just having to set up an smtp daemon every time, and having to maintain it, is such a pain in the ass. Probably most tools have moved on by now (I moved away from mutt in 2004 or 2005) but I used mostly postfix and qmail (when I got fed up with one I switched to the other for a few months, etc). Just having to remember the dozens of idiosyncrasies in those was enough of a PITA to make me switch to an integrated graphical mail program.
My main method of searching email was grep -R ~/.Maildir . When I think back about that - ugh.
Once you are "inside" an app instead of your shell prompt, you are no conforming the Unix ideal.
I found this tutorial that I wanted to follow in that thread: http://stevelosh.com/blog/2012/10/the-homely-mutt/
I do have offlineimap and mutt already setup and I can read emails, but haven't installed notmuch or done any configuration. Seeing 1.6 release reminds me that I should give it a fair try again.
Mutt 1.6.0 was released on April 4, 2016.
Mutt 1.4.2.3 was released on June 9, 2007.1.5.X was a development series.
Edit: T-Mobile "unlimited" is bullshit. It is only unlimited for the phone itself. Hotspot usage is rate limited to an unusably slow rate after data allowances is used (the limited rate is usually well below the 128kbps they claim, but even when it is reaching 128bps, that's unusable for the modern web, and the latency is horrific, so even shell sessions are impossible once you hit the cap). The only reason I stick with T-Mobile is BingeOn lets me watch Netflix without using much data; though the crappy speed of it makes it unworkable in a lot of locations. But, don't believe their marketing about "unlimited" data. It is not. T-Mobile also seems to measure bandwidth usage in a shady way; I use about 1GB a day on Karma...same kind of usage results in 2GB+ a day on T-Mobile. I haven't analyzed what's really going on with any precision, but I've noticed the discrepancy on a few occasions; it has happened often enough and to a large enough degree to where I think the smoke is indicative of a fire.
For those rare HTML-only mails, just install lynx and add this to ~/.mailcap:
text/html; lynx -dump -localhost -force_html -width 80 %s; copiousoutput
text/html; /usr/bin/w3m -I %{charset} -T text/html -o display_link_number=1 -dump; copiousoutputPS: some of khal's wonkiness is due to it reporting all errors instead of silently ignoring them most other calendar software does.
I do wish that there was an option to treat threads as the primary unit, like gmail and sup (http://supmua.org). The threading support isn't bad, but expanding and collapsing threads in the index view only gets you so far. Years ago I took a look at the code base thinking I might give it a try, but quickly realized that kind of change was a lot of work and way over my head.
I don't hear that often from people, but that was also one of the motivations for me to switch to mutt.
Still, mutt is my main email client. I only started using it a couple of years ago, after Thunderbird started to strain with my mail folders. In 1990s college days, I used Pine. Mutt scared me back then, tho mostly because no one I saw using it then edited with Pico.
To keep a similar feel I wrote my own mail client, with integrated Lua. It might be topical, even with all the mutt-love and nostalgia here:
Anyone know if the hanging between wifi to cable connections is resolved yet? Aside from that I'm much quicker and more productive with my inboxes now. Sidebar patch, hotkey per mailbox... Very quick icedove replacement.
PS: Workaround for the connection thing is to ctrl-z when it hangs, and fg the other instance for that connection.
Good to have this, although most of what I get these days (work-wise) is HTML-formatted or otherwise challenging from a readability perspective. I fully intend to give this a go against my mail archive (which goes back to '98, and which I currently access via Thunderbird, running inside a VNC server on an ODROID-U2 ARM board - which is a bit heftier than tmux...)
`text/html; w3m -I %{charset} -T text/html; copiousoutput;`
For interactive terminal web browsing I prefer links/elinks (again, compared to lynx/w3m a long time ago).
I have it integrated with a browser for those annoying HTML emails that it can't interpret, but it can handle most HTML emails.
I think it has some psychologic benefit to help me calm down and read the big pile of mails.
Alpine is currently maintained by Eduardo Chappa.
I just committed a patch about LDAP. Eduardo Chappa is a very diligent developer.
With those settings gpg mail is very simple to do, and of course since its mutt its endlessly configurable if you need it.
Even more, I can still use mutt if I want to. But mu4e is so nicely integrated with the rest of Emacs that I think I'll keep using it.
[0] http://paul.kuntke.de/blog/2012/07/16/view-images-in-mutt/
https://technet.microsoft.com/en-us/library/jj657728%28v=exc...
"By default, POP3 and IMAP4 are disabled in Microsoft Exchange Server 2013. To support POP3 clients that still rely on these protocols, you need to start two POP3 services: the Microsoft Exchange POP3 service and the Microsoft Exchange POP3 Backend service. To support IMAP4 clients that still rely on these protocols, you need to start two IMAP4 services: the Microsoft Exchange IMAP4 service and the Microsoft Exchange IMAP4 Backend service."
One workaround is to forward all your emails to a IMAP-friendly service such as Fastmail using Exchange rules.
Opening an IMAP mailbox with 100.000+ messages takes 60-90 seconds. And caching does not make things much faster. :(
now that gmail and yahoomail give imap for free, they will surely comeback. see N1 for example.
All sane mail providers offer SUBMISSION (same protocol as SMTP) on port 587, which is intentionally not blocked by ISPs.
Of course, they only needed to block port 25, but alas they blocked them all.
[1]: http://www.rcs-rds.ro/asistenta/protejeaza-ti-calculatorul?t... (in Romanian)
[2]: https://www.telekom.de/hilfe/festnetz-internet-tv/sicherheit... (in German)
Desktop MUAs won't suddenly become popular now. A generation of users has been brought up on webmail, and the idea of using a separate program for email on the desktop isn't familiar to them.
[1] http://www.wired.com/2007/10/google_adds_imap_support_to_gma...
The person in question is someone who became "computer literate" relatively recently (at least compared to me, I'm 37 and always been tinkering since I was a kid) and has become accustomed to most on-line services while using smartphones and tablets, not a personal computer.
That person is not alone. To be honest, I think most people under 20 and most people living in developing countries went down a similar path (mobile first) and have a similar understanding of messaging platform.
Last updated on November 30, 2001 by Jeremy Blosser.
I look at Mutt willingly once about every 3 months, but then I'm always put down because of the last of Snoozing (that I've know off). I rely heavily on Snoozing in my main account to order my tasks.
Is there any workflow with mutt that achieves a similar workflow where I can postpone emails to a later date?