Switching to the Mutt Email Client
nullprogram.com
nullprogram.com
Integrating mail with Emacs was the best idea ever, because Emails include either todos or serve as reference in projects. Creating todos from Mails as well as linking to them from org-mode is only a shortcut away.
I have never had a more easy to manage and productive todo management system - and it's all text, so there will never be breaking changes or paid upgrades or incompatibilities between tools that I cannot fix.
this is the only solution that i found to work for me. I know that i have to handle it now inside wunderlist. but it works ok for me because is better sorted.
i use evernote for some of the stuff, and i try to write everything. sure its not ideal but it is a lot better then it used to be where i would forget about some important stuff.
But my links to mail from Things and EN kept breaking. I also work with Inbox Zero and that's the primary reason for my switch - without references it got worthless.
So, I am slowly retracting and going back to vim, Mail.app, Things (and mutt every now and then ;)).
I'm not trying to be mean, it's a great project, of course.
I have my own configuration on top of vanilla Emacs and have never had any problems with things stopping to work.
As for iOS I don't need more than what MobileOrg has. I need to add new todos and very seldom look stuff up. Both work totally fine. And I'm saying this after having been a paying Evernote and Things user for years^^
There are lots of these around, but if you're interested in trying it out I have a pretty simple Spacemacs layer for Notmuch as well.
Maybe things have changed now, but several years ago I wanted to setup Gnus, and asked for help on IRC (#emacs IIRC) because there weren't many good resources online. The response was "if you need to ask for help, then Gnus isn't for you."
Gnus is fairly painful to set up. I did write something up several years ago about getting it going the way I wanted (http://www.cataclysmicmutation.com/2010/11/multiple-gmail-ac...). I haven't used Gnus for a few years now, having first gone to mu4e and now due to corporate fun, Microsoft Outlook, so that document may or may not be currently useful.
However, mu4e is pretty straight forward and has a strong search engine included which means that I can use my setup on both Linux and the Mac. As I understand, I would need to set up a local mail server for Gnus if I wanted reasonably fast search. Having multiple (and sometimes changing) mail accounts that I would need to configure on multiple OSs kept me from doing that.
So to me, mu4e is easier, though Gnus might be simpler in the true sense of the word.
Not saying that Gnus doesn't have merit, though. It's a fascinating piece of engineering. And when I get older (already old^^), and only have one business running in parallel and no more need for the Mac, I'll probably switch(;
I ask, because in the past I toyed with switching to using Emacs as my e-mail client, but aways got stuck on configuring the whole setup to work reliably and seamlessly.
I use OfflineIMAP to sync the two accounts to ~/Maildir/{work,personal}, then mu4e-context to switch between settings for the two.
I entirely outsource actually sending the mail to a local exim4 daemon which is configured to forward through a GMail smarthost. IMNSHO this is much better than the recommended default configuration of making Emacs actually send the mail, I don't have to worry about not having a network connection at the time, or some other transitory error with a real smtpd retrying the send if needed.
You then may need a tiny hack on top of Debian's default exim configuration to make it switch between different smtp servers / accounts depending on what address you're sending mail from. For reasons I won't go into I send E-Mail through a company-run SMTP server even though I then fetch work E-Mail from GMail.
I'll definitely consider your trick for sending e-mail - I definitely value both Emacs not hanging and also having the ability to send e-mails off-line.
I'm using Mu4e with 4 different mail accounts, though and it's completely seamless and easy to compose.
If you're interested, you can check out my configuration (which is written in literate org-mode so it's actually easy to read^^): https://github.com/munen/emacs.d/blob/master/configuration.o...
How's your experience with literate config, in terms of managing it? I've been meaning to switch from my mess of individual files to something like this for a time now.
Regarding literate configuration: It's been super easy, honestly. I used to have a longer init.el (formerly super long vim.rc^^). Once I wrote a short macro that converted comments into new headings in org to get me started. Then, every time I touch something, I just add a little more documentation to guide me and others for the next time. It's not more work than writing a regular init.el with comments, but the result is so much more powerful (folding->refactoring, documentation on Github, etc).
Can only recommend it, at least for Elisp.
In most big companies you can't really afford to do any email client shenanigans. You probably need to see HTML emails, handle calendar invites, etc.
Modern shared calendars arguably provide negative value versus simply keeping a private calendar.
I think it all depends on which area of work you are in. For software engineering folks it works just fine.
I for one use mutt and handle calendar invites with gcalcli, I can use LDAP lookup and HTML mails are converted using elinks and read inside mutt. If I want to see all the fanciness I just open the text/html attachment in Firefox.
> In most big companies you can't really afford to do any email client shenanigans.
So... what does the percentage of employees using Mutt have to do with that?
I still use Mutt to quickly prune emails in the AM and for writing to mailing lists.
I've (sadly) gotten pretty used to Outlook and like it quite a bit. I do miss using vim to edit emails though...
As for HTML email, what I take from this entire thread is that I either I've been extremely lucky so far or people in general vastly overestimate the importance of it. For one thing, most decent services will send multipart/alternative emails that are suitable for plain text display.
For instance Amazon's emails use rich HTML features, but they also have a text/plain alternative that works perfectly in a text client and carries the same informations. And when there's only HTML the vast majority of the time it's still mostly text with some light styling and it works just fine (sometimes better) in text mode.
The main problem working in big companies and using mutt as my client is that most of the time those systems have a 2nd class non-compliant IMAP servers and you have to go through oops to reliably receive and send your email. I always managed to get it to work after some tweaking though.
The biggest issue with that is when the sender of the email doesn't actually check that the content was converted properly. Most notably, hyperlinks in the HTML get converted to the text of the link and the URL in question is no where to be found.
Even if most HTML emails send perfectly created plaintext versions (and yes, Amazon is great at this), you'll remember the crappy unreadable HTML-only emails far more than the normal looking multipart ones with proper conversion of the HTML to plaintext.
My first job in high school involved formatting and sending out email blasts. Even at that point, I was aware of potential formatting issues and I took care to make sure that the automatically generated plaintext version had all the same content. For that reason, I have no patience for HTML-only emails crafted by grown adults.
At work I use Outlook only for the calendar.
At this point, it's pretty rare for me to get an email that I need to read that I can't, mostly those are spam or sales messages. Where I work, the company uses the "G Suite" of products.
Best thing about this article. Unfortunately he didn't derive anything from this wise statement.
I happily used emacs as my mail-reader from 1989 to about 2009 (first RMAIL mode, then VM). The increasing importance of non-text formats made it cumbersome, and I somewhat reluctantly switched to GMail. It's hard to imagine switching back now.
I can't imagine it. Too much valuable information comes in the form of rich emails for me to even try.
And then you have people who start using formatting semantically, e.g. colors.
Now, with all of that said, Emacs does a remarkable job of rendering a subset of HTML. For example, I have my mail client configured to always ignore HTML alternatives unless they're the only option. In that case, colors and tables and such are all rendered as they should be. Inline images might be supported if you use a graphical version of Emacs (Emacs can definitely display images, I just haven't tried in this context); you also have the option to open it in an external viewer, like a web browser.
As for attachments, you can open them in their native programs just fine.
Sure they do, by attaching them.
It's all quite painless really.
https://github.com/jezen/dotfiles/blob/master/.mutt/muttrc#L...
One of the few reasons I have to mess around with NoMachine etc is for email, if I could get it in a terminal over ssh that'd be great. I did try a few years ago and after wasting a lot of time sorting the config, the lack of good reading experience for rich content emails was enough for me to dump the whole thing.
I don't know if you are joking, but this was not uncommon for quite some time. It used to be that color printing was much more expensive than black and white. Text books often only had a few pages with illustrations and images in color. The color printed sheets were added last so they ended up exactly in the middle of the book.
> it doesn't exist anymore
Email clients like gmail/outlook put images in the content of the email (NOT an attachment) when you drag/drop files onto the window or when you copy/paste a picture inside the mail.
There was a time when this all went to attachment, that is not the case anymore.
Sure it can be cumbersome if the various images are interleaved with commentary, but in my experience 99% of the time it's "Here are the pictures/documents you wanted" followed by a few attachments (inline or not).
There's a very, very small proportion of emails where HTML is actually mandatory to make sense of the contents. And for those I can just tell mutt to load the HTML in my web browser. I very seldom have to do that though, not enough to be a real nuisance.
I am not sure of your definition of normal. ;-)
Part of my duties at work include help desk and maintenance of a few pieces of software. I get eMail with screen shots of error messages on a fairly regular basis.
(Personally, I have made my peace with HTML eMail, what I really dislike are those humongous email signatures with corporate logos and silly disclaimers that often dwarf the email body itself.)
Normal people send me pictures in emails all the time. Very often it's a screenshot of something where they have drawn a circle around some part and written some variation of "this part is wrong" or "can you take a closer look at this".
They shouldn't but they do. Almost every time someone sends me an image I think of a better place they could have put it. Attached to the ticket in our ticketing system, in our bug database, on our file server, etc
You don't get to dictate what features of email people should or shouldn't use.
Apple's Mail.app has a great feature that allows inline markup of images, which is a huge boon for interface discussions and tech support emails at my company.
At my old job, as an engineer, I also put images inline. I got emails all the time, or calls, asking why is this? The easiest way to show someone is in an email, with a screenshot.
Its not any different than an article in a newspaper or on a webpage with an inline image. It actually just works.
Despite my "Why Be Normal?" visor, I consider myself mostly normal. I send and receive email with inline images. Sometimes they're attached, which is usually annoying, unless they really aren't part of the narrative.
Normal people do it, because it's part of email.
"Normal People Do It" would make a great visor.
This is absolutely not true. Generally speaking, people whose experience leads them to think this are in weird isolated silos where highly technical folks are overrepresented.
For non-text formats, I only deal with HTML. For them, I pipe the mail through a terminal-based browser before reading it. All of this is done automatically, literally a one-line configuration in the proper file, a thing that is explained at length in most mutt guides.
(The other is "I'm old enough to have been using text email since before graphical email clients were a thing and don't want to change.")
and even if it were the truth: navigating mail generally consumes the least time... actually reading the mail and deciding what to do about it takes way longer. another activity where a scroll wheel is invaluable.
Depends on the kind of email you receive.
I'm a heavy VIM user. Gmail supports VIM keybindings and there exist VIM keybinding extensions for all popular web browsers, i.e. Vimperator on Firefox.:wq
That said, I still find Thunderbird better than mutt, even though it takes ages to do anything and crashes 3 times a day.
that's what they said back in the early 2000s too, so I tried it, but I was appalled by the horrible support for message threading and IMAP support that was missing most of the features you'd expect an IMAP client to have plus the stuff that was there was full of bugs.
I'm sure this has gotten better by now, but a blanket statement of "Graphical clients are buggy" is totally not valid. All software has bugs and depending on your priorities some might be worse than others.
* A good integration to the rest of my IDE. I need to save a chain of email as .mbox to `git am` them afterward. I have this workflow with mutt, I don't know which graphical email client would allow me to streamline this.
* In the same vein, I need to be able to use only my keyboard. I tried a little using a web client with vimperator. But the gmail interface wasn't really easy to use, I prefer using mutt properly configured.
* I also like writing my emails using VI. Having those keybindings is a proper crutch, but it's not there for text editing.
* Finally, it allows me to have a transient workspace. I can SSH on my main machine from wherever, do a `tmux attach`, and I have absolutely everything available: access to my emails, but also integration to my other tools for email analysis / processing.
This all stems from workflow derived from ancient practices, that's true. When I was starting in the industry I mostly used graphical tools. More and more however, I tend to rely on purely TUI tools. I have a few things that I can simply not give up anymore (grep, find, sed, awk, as well as full access to git).
I only use the web for accessing articles or content aggregator like Hacker News, as well as streaming music to block the open space. Ah, yes, patchwork remains web-based, I haven't really used pwclient. When I have time I will look into this.
Think about how word processors were a thing so early in personal computers, despite then actually being some of the most complicated bits of software one can build. What are e-mails if not documents?
Having some control over formatting (at least in the semantic sense, like HTML) is a core part of using computers for a huge part of the population. Yes, even the people using only their phone. People like bolding text.
A lot of people aren't good at it, but a lot of people aren't good at talking either.
I submit your understanding of how email works for most people in 2017 is outdated.
Email with inline images is common, useful, and not going anywhere.
I'd argue that images in emails means that you haven't reached 2017 yet, where there are loads of better options to share images.
Images as links to something else, that require an additional step, are an inferior substitute to inline images. Here in 2017, it's possible to build an email that includes tables or screenshots or other rich media that exist as part of the email itself.
This is commonly viewed as a benefit. 20 years ago, I, too, was resistant to the idea that email should be something other than plain text, but I was wrong. That ship has saild. Email today is a rich document, and rich documents often include meaningful inline images that should be stored with the document.
Again, that YOU don't like this doesn't mean it's not useful or widely used by other people.
Can you name a few examples of such rich media emails you recently received or sent and to/from whom (categorywise, e.g. family member, colleague, customer, department type)?
Obviously, people use email in different ways. This thread seems to have attracted a large number of people who exist in a text-only email world, but nearly every email I send or receive includes at least some rich formatting, and it's very common for us to include inline images of screenshots or other graphics as part of these emails.
And we're not web designers. We make project management software.
So: for me, mostly work email, though I certainly get no small number of personal mails with photos attached.
Again, that YOUR experience with email doesn't include rich text or inline images outside your spam folder doesn't mean those features are valuable and useful to other people.
* http://jdebp.eu./Proposals/gnksoa-mua.html#NoAutoFetchExtern...
Now I use Claws Mail with Emacs as the editor. This solution lacks integration with Org-Mode so I may end up going back to Emacs.
That said, there's a happy medium between console based email and bloated, buggy clients like Thunderbird. Claws Mail is a very old-school graphical client that supports modern email features, and it's about as tweakable as it gets.
Is there an email client that, when you drag a file icon into the composition window, doesn't attach the file but instead uploads the file to cloud storage and inserts a link? Now that I think about it, that's basically what Apple Mail's Mail Drop feature does (file is uploaded to iCloud, I think on send, recipients don't have to use Apple Mail and the file only remains on the server 30 days).
Thinking about the usual steps to attach a file compared to including a link to a hosted file, I think the latter much more takes one mentally out of the composition mode to deal with the hosting/sharing; dragging in a file attachment
"I'm writing an email that references a file. I get out of email to find the file. I'm dragging the file into the message window. I'm sending the email, it seems like its taking longer to send because it's a large file attachment."
"I'm writing an email that references a file. I get out of email to find the file. I move (or copy) the file to my cloud storage place (Dropbox, Google Drive, etc.). I set the file to be shared. I copy the link to the file. I go back to my email and paste the link (or write some link text in HTML email and paste the URL). I'm sending the email."
Trillian is IM, but I believe it works that way
Are you actually convinced of that, or are you being inflammatory? Because, in 2017, it's hilariously far afield of most folks' email use patterns both at work and at home. Do you only ever communicate using text -- and plain text at that?
I work for a small software company - ie, full of nerds. We use screencaps marked up in email ALL THE TIME to communicate about changes and whatnot. Sure, I guess we could put it in a Word doc or HTML doc, but why bother when we can do it in the email client?
In my experience, it is rare that I need to look at an image or pdf, etc.
I'm not doing web development, so there is no particular reason any colleague would send me a screenshot.
Again, these are my observations and perhaps my window isn't big enough.
With a distributed team, it's even moreso. Plus, since we're distributed, the idea of email-as-document (with rich formatting and inline images) is just that much more normal.
I am a researcher, and when my colleagues want to discuss results they have the nasty habit of sending plots and documents as email attachments. My most important emails have PDF documents or plots attached, with the email text commenting the attachment itself. The problem with mutt is that it allows you to start helper supporting application to open attachments, but it waits for the application to finish before returning to the email text. This is not what I want, for I obviously have to read the email and view the attachment at the same time!
The usual trick here is to fire the application in background (using "&"), so that mutt can resume operations immediately after the helper application has started. The problem is that once mutt resumes, it removes the temporary file containing the attachment, so if the helper application starts slowly it might not find it. One can force mutt to wait some seconds after having launched the helper application, but this not helps if the attachment is a multi-page PDF file, because once the wait has expired, the PDF file disappears and is no longer browsable.
I must say that using mutt was an enlightening experience (email browsing can be fast, after all!), but thunderbird makes me far more productive.
:-)
I find the emacs editing experience so superior to anything else that I feel hamstrung in Gmail or Outlook.
- VS/Xcode don't support keyboard macros
- VS/Xcode don't support piping selection through a shell command (I had to write an addin to do it: https://github.com/tom-seddon/VSScripts)
More generally, your window layout options in both are a lot more limited, and, worst of all, the extensibility experience in both is poor. Extensibility is basically non-existent in Xcode, and while it looks comprehensive in VS the APIs are rather unwieldy and underdocumented and the iteration time for testing is very bad.
Good extensibility support opens up many possibilities! Even with what VS gives you, you can get good stuff like Comment Reflower, or (if I say so myself) my VSScripts addin. But Emacs just does that side of things a lot better.
For example, multiple-cursors.el, which is an Emacs addon, is a huge improvement over the box selection available in VS/Xcode.
Adding reasonable support for a language to Emacs is easy to do in a couple of hours, possibly working from one of the many examples, and you can continue refining it from there. In VS by contrast options are the two extremes of "pretend it's one of the other languages VS supports already" (little better than Notepad with syntax highlighting) or "invest a week (plus) in writing an entire new language infrastructure, with no examples to work from" (I'm sure the results are good if you put the effort in though). For most under-supported languages you'll meet, Emacs is much closer to the effort/reward sweet spot.
(Xcode? I don't think you can make it support new languages at all.)
It's been a while since I used WebStorm (Javascript-oriented IDE) but my response to that was similar.
You must have a very different set of correspondents than I do. About the only non-bulk, non-plain text mail I get is when the office manager sticks a cute .gif in an announcement.
Emacs gives you tight integration for everything that could possibly be represented as a buffer. Emacs is programmable glue between applications, a better "shell".
The desire to do all things in Emacs is because Emacs lets you do it and because it reduces context switching. For more on why one would want to make Emacs do things that are not traditionally the job of an editor, see also https://elephly.net/posts/2016-02-14-ilovefs-emacs.html
But, just as it is a mistake to blindly cling to the old and comfortable, neophilia is a trap in itself. And it is a bit amusing to watch, for instance, new crops of editors repeat the same mistakes old ones got through in whatever GUI drag is trendy is this week.
For your Mac OS comparison to make any sense, you'd have to point to something comparable to lacking memory protection. So... what would that be? I have a sneaking suspicion you mean GUI integration with whatever OS you use, but I'd like to be clear.
Agree, there is always must bee a meedle path.
To answer your question about MacOS 9 comparisons, I meant technical limitations, like single threading issues, ui capabilities, you know. I may be wrong, though, I haven't paid attention to Emacs intervals for a while. Modern web-based platforms are far from perfect, but they are reacher.
Emacs lacks a couple of features and I think it's fair to say that this represents a limit, but I don't see "the rest of world [...] moving forward" in this area. I don't know of any other system that is as ambitious as Emacs, a system that embraces the overflowing kitchen sink and isn't content with just being called an editor.
Out of the box it's terrible, I give you that. Clunky and dated are too nice for describing the defaults. But underneath the extremely conservative and curmudgeon defaults lies a very flexible environment that cannot be approximated with a set of text applications running inside a terminal emulator. It's a pale shade of the same colour that made Lisp Machines so attractive.
The vi vs. Emacs editor wars are over and Emacs lost. The new struggle is between vim and modern IDEs and IDE-like editors (Atom, Sublime, etc.).
There are reasons for this. Vim is retro like beehive hairdos; Emacs is retro like casual workplace sexism. The buffer implementation in Emacs sucks. Once you start opening huge files or running shell tasks that spew a lot of output, Emacs chokes hard and because it's not multithreaded, pegs your CPU and locks up your terminal, in buffer sizes that modern editors handle easily.
Also, Elisp is slow, contains warts the Lisp community has long since fixed, and is in general a millstone around everybody's necks.
Also, the UI. Just... the UI. Wonder why the best way to get a young developer to use Emacs is to reskin it like vim (evil-mode, Spacemacs)?
Editors, even all-in-one kitchen-sink editors, have moved on from Emacs. Just let it go.
I learned vim first and later switched to Emacs because it allows me to integrate all tasks in the same work environment. The defaults are admittedly terrible and it's certainly far from perfect. But I don't see any alternative that works better for the things that I use Emacs for. I am looking forward to eventually be using Guile instead of Elisp, though.
Curious that you mention the UI as a negative(?) --- the Emacs UI is pretty good actually and it's very extensible.
Well said.
But: I have been using mu4e + Emacs for email for about two years now. I would seriously recommend anyone who already uses Emacs -- and especially if you use org-mode -- to look into it. Not because you score nerd points for reading & composing email in Emacs (frankly, you look ridiculous) but because it might just hook in perfectly with your workflow. I hardly touch any of the power user features, I do very little customization, and still it is by far the best way for me to manage my email. I also use it side by side with a web client (both Fastmail and Gmail) and switch if I need to.
How does an emacs window, even with mu4e, represent emails with meaningful formatting, inline graphics, etc? I'm guessing by launching an external viewer, but even that would slow me down quite a bit.
For basic formatting (bold text, headings, lists, links, etc etc), Emacs can render using its built in web browser. The "richer" it is, the more screwy the formatting gets. Usually you can at least read the emails.
You can easily pipe an email to your web browser of choice. This works fine but isn't exactly what you want to be doing all the time.
For my work, I am mostly dealing with plain text and attachments. The rich stuff is usually the email I care less about anyway. I don't think I'd want to use mu4e if I was dealing with rich content often. You can do it but it definitely slows you down.
I use Alpine for personal email and Gmail for my work email, and I've wasted more time configuring the latter than the former.
You're completely missing the point.
Sure, some people might do it to score points with their peers, but many of us use text-based clients because it fits well within our workflows. I used to use Mutt, because I do everything except for graphical web browsing (literally) on a terminal. I switched to Gnus in Emacs because it's heavily scriptable and has very convenient integration with Org Mode.
While I do use Emacs as an IDE (I do some work in Clojure), I have another instance that I keep open and use solely to manage myself: email, calendar, list of to-do items and their status, miscellaneous notes, etc. At one point I had separate tools for each of these functions but over time I've decided that specialized tools aren't really worth the hassle. Emacs works just fine and everything is in one spot and easy to find.
Put another way, you can complain that a pickup truck isn't a Prius, but you should expect people who use (not just drive) pickups to snicker.
I use mutt (and vim, but that's a different post) heavily because it saves me so much time. Sure, there's a learning curve, but there is no faster mail client out there for handling large volumes of mail.
Speed:
- It is entirely keyboard driven.
- Until you have >6 figures of mail in one mbox, every action is essentially instant. And then you only wait a bit on load/save.
- If you have to deal with automated mail systems and the occasional mail disasters caused by them, the regex manipulation is a godsend.
- I think people don't notice the little delays in GUIs, but when you're going through hundreds of messages, it adds up.
Other awesome features:
- If you ever have to deal with GPG, mutt is the place to configure it. I don't use it much, but it is part of the workflow for some open source projects. I've configured it in various GUI MUAs, and it seems like every time I do try to sign something, it broke in some annoying way. Mutt is loosely coupled enough that that doesn't happen.
- Works over ssh. Yes, this absolutely matters to me - can't live without it.
- Extremely extensible. Add a configurable MDA[1]. I've built entire little adhoc apps based on email for various purposes.
[1] I actually still use procmail, because the syntax ate by brain a long time ago, but I'd recommend something less obtuse if you're starting fresh.
Mutt is a bit old-school. It absolutely assumes rather more familiarity with how mail works than most other MUAs, and the configuration isn't very... ergonomic is the wrong word, but close. Combined with man(1) style docs, there isn't a good way to distinguish obscure knobs one would rarely want to touch from things everyone configures, for instance, unless you're already pretty familiar with what's going on.
In a past life, I spent a noticeable fraction of my career dealing with email from several angles, and love mutt. But if you've made healthier choices, I can absolutely see being bewildered and frustrated by it.
The Mac mail app would be totally sufficient for me if it could handle complex searches over the volume of mail I have with speed, but it just doesn't. It helps that I'm in an organization with a disproportionate number of Linux users; I don't get any Outlook attachments or other Microsoft nonsense in my inbox.
Having a real scripting language allows a lot of useful features, at times using mutt felt a little bit too constrained, although it has a lot of features and is very very flexible in its own right:
Recently it landed full Lua scripting support as well. Guess you're not the only one that was looking for more powerful configuration within mutt.
I'd be very happy to have more feedback and help to extend further that API and have some great scripts happening!
For example you might have a folder of "backup results", you'd want to mark all that have a subject of "Backup OK" as read, and flag the ones that have a subject of "Backup FAILED" as "important". Those are the kind of tasks I automate with my lua-based mail-client.
You can get more interesting and say "Keep only the most recent 100 messages in folder XXX" which applies whenever you either launch the client, or open a given folder too.
~/.muttrc: alternative_order text/plain
One concern is that I'm letting through all web bugs and, perhaps, outright malicious HTML. If anyone has a solution for that, something like filtering the HTML, I'd love to hear it.
No, but HTML emails, 99% of them, are just plain text in an HTML markup. You won't miss garish colors or font choices.
As for embedded images etc, you can still view them with plain text mail clients (as attachments).
If I really end up having to read an HTML email those can be displayed "inline" using a text browser such as w3m. If the HTML is mostly text it works pretty well, for instance: https://svkt.org/~simias/mutt-html.png
If however it's image or css-heavy and doesn't work well in text-only form there's still the option to tell mutt to open the email in your web browser. Of course in this case there are security implications so it's probably best not to do it from untrusted sources.
https://www.neomutt.org/changes/user
Edit: third question, how do you read mail on your phone? A couple of questions for the author. How do you handle attachments and do you download mail over POP3/IMAP or do you have your own server (hence SpamAssassin) ?
Some people use this to turn their smartphones into a laptop. I guess you can use it to read email too:
https://www.marcbilodeau.com/termux/
edit: this makes me want to buy a smartphone with physical keyboard. maybe I should pull the trigger on the Blackberry keyone...
Every now and then I'll go on a spree to zero out my inbox, and I find doing this with mutt's search/tag/move/delete workflow is a lot faster than messing around with my mail provider's application (Fastmail's, which is awesome, and Gmail's, which is less so) or any other client I'm aware of.
Some resources I found helpful:
- http://stevelosh.com/blog/2012/10/the-homely-mutt/ (good, but it recommends offlineimap — I tried it and found it to be slow and buggy. mbsync is much better.)
- https://github.com/cbracken/mutt
- https://lukespear.co.uk/mutt-multiple-accounts-mbsync-notmuc...
So far its been worth it. Instantaneous search of all my email ever. With a properly configured mailcap file HTML emails are rendered ok (still have problems with links) and attachments open in external programs as well.
Since `alot` is written in Python and can be extended with Python hooks for almost any event it has been easier for me to customize than emacs.
Follow my configuration: https://github.com/javier-lopez/dotfiles/blob/master/.mutt/m...
To the comment about mutt's poor addressbook support, you can use it with a CLI/CUI app called addressbook that's quite good, and you can interface with with other addressbook scripts to access carddav servers as well. I'm intrigued by the links to carddav support.
For me, the HTML email and calendar invite issues are trivial, and grossly outweighed by the efficiency I get with mutt by being able to select and act on huge amounts of mail at once. The threaded view is essential. In a pinch, I use sylpheed/claws or even Thunderbird. But after using mutt at home, going to work where I'm forced to use Outlook makes me want to claw my eyes out: in my opinion, Outlook has gotten worse every year, and is barely useable at this point.
Meanwhile in mutt, I can do things like "delete every message between dates X and Y and sent by person Z." It makes dealing with huge amounts of mail effortless. I also tire of editors, and cycle repeatedly through emacs, vim, slrn, and joe/jstar/jmacs - I love the flexibility. I combine it with Fastmail/IMAP, and wouldn't dream of going anywhere else. Gmail isn't for me: if it works for a lot of you, congrats - I'm past the point where I care about converting others to what I consider "the one true way." Just wanted to add to the conversation my opinion that the day they I can't use mutt for email is the day I stop emailing, period.
I used mutt for about a decade. I got sick of it being a bit too constraining (e.g. could not auto-Fcc to multiple folders based on To fields). And frankly, for the last 5 years of my usage, there was no real development.
notmuch is great for me. Using tags and Python, filtering incoming mail is a lot easier than with procmail's arcane syntax. I've recently set up a whitelist email system to get rid of unwanted emails. If a "new" person emails me, they get sent to a web site to confirm their identity and their email gets put into a quarantine folder (not inbox). If they go to the web site and confirm, then my mail system moves their email from quarantine to the inbox and their email address is whitelisted.
No more junk mail. The only mails that get to my inbox are from whitelisted accounts.
Notmuch with tags made this a trivial thing to code.
But ultimately when gmail came along I realised there was a better way. It is only a problem that we give up our privacy and agency by using Google's software and computers. And nobody was checking my PGP signatures anyway.
If you feel like you want to get the benefits of a nice email GUI, in a sandboxed browser, but also want privacy and some control, check out Mailpile:
It isn't finished, but it is promising.
I already use enough arcane tools on a daily basis due to my work. For mundane stuff like reading and sending mail, I'd rather take a break and use tools that even my tech illiterate father could effectively use.
It's really detoxicating to become a normie from time to time.
Disclaimer: Used to read mail with emacs back in the day. Tried mutt for a while.
You don't even have to memorize the action keys, Alpine shows the available actions for the current screen at the bottom, with helpful labels. It's arguably clearer than Gmail, with its unlabeled icons.
Mind you, that's on a secondary email account; if I need to handle images or attachments I forward it to gmail.
Opening the text: That looks like 5% of what people need to get started. If you could summarize it to such a degree everybody would use mutt.
So i just did to test, and it is horrible! :)
But, unfortunately, I had to go back to Thunderbird. With the exception of free software mailing lists, people simply do not know how to use email. Bottom quoting is the default. We can thank Microsoft for that one, I think. I can't understand why anyone thought it was a good idea to attach the previous message to the bottom. Most people just accept this as the way email is and never question how unbelievably stupid it is.
Then you've got all the HTML shit that people put in there. And the fact that many clients are simply broken and don't write the headers correctly which breaks threading. This is often confounded by broken servers which garble the headers a second time.
It's amazing that something as simple as mutt or gnus (emacs) has everything you need: threaded messaging and convenient composition. Inline quoting is surely the only sane way to do quoting. Why would you assume the person you reply to has deleted their own message? My message to you is right there in the same thread in my client. Don't send it back to me. But do make it clear which parts of it you are addressing (inline quoting). You had to laugh when Google reinvented threaded messaging in the 2000s and advertised it as some groundbreaking new thing.
So I gave up. I use a client that can deal with the stupid shit that other clients spit out. I also bottom quote now. Why? Because if you do inline quoting, MS Outhouse web client thinks that everything after the beginning of the quotation is a copy of the previous message and folds the whole thing, meaning your recipients get back what looks like an empty message. Really.
Gah; that explains it. Occasionally I get a reply saying "you just sent me a blank email", while the text of my email is quoted right there in the email they've just sent me!
(And yes, I miss the days where SMTP & NNTP servers would actually enforce the ratio of non-quoted lines vs. quotes lines, forcing users to trim the relevant parts of the message they are replying to.)
I think a lot of email clients expect that type of quoting/top-posting (conversation view for example). Another problem is that certain mobile email clients make it impossible to not bottom-quote. That is, they just present a composition window and don't give you the ability to position your text within the quoted email you're responding to.
Though I do find it interesting that people on Hacker news, Slashdot, and reddit will generally follow the convention of responding inline if they quote the parent post in their response. I don't recall anyone ever following the email "convention" of bottom-quoting.
Most people actually don't quote at all. It's just that the majority of mail clients out there, including the Web ones, quote the message being replied to and position the cursor above it, and no one takes the effort reformat it, or remove it.
Software needs to make it easy to choose portions of the message and automatically quote them in replies. Currently the usability of that aspect is broken. You have to cut and paste manually. A lot of messaging systems don't even add '>' marks.
On HN, this is handled entirely by wetware - there's an unofficial convention. You quote the relevant part of a post by preceding it with '>' (but not turning it into a text area!). Many people (myself included) also italicize part after the '>' to make it more visually different from their response.
Actually, they don't. Most posts don't quote their parent at all, it's a unitary response to the full parent post. Which is what bottom-quoting does - it doesn't actually quote the parent post, it leaves it in for reference (which makes sense because email clients, unlike HN, are pretty crap at keeping track of conversation threads).
Very few people communicate in the super-structured way that in-line quoting implies, that you go through an email sentence(/line/paragraph) by sentence(/..) and respond individually to them. It's super-arrogant, and thankfully getting very rare, to insist that your way, just because it was first, and then completely failed to catch on, is the one true way and people are "unbelievably stupid" to disagree with you.
> Actually, they don't. Most posts don't quote their parent at all
I never said that most people do. When you quoted my post in your response, you left off the clause where I said: "if they quote the parent post in their response".
> It's super-arrogant, and thankfully getting very rare, to insist that your way, just because it was first, and then completely failed to catch on, is the one true way and people are "unbelievably stupid" to disagree with you.
This aptly demonstrates that there value quoting the relevant parts of the post you're responding to. In this case, you're attributing statements that someone else made to me. If you want to argue against what you're quoting, then you should reply to the post that actually made those statements.
I hate to think of the hours wasted due to ambiguity in email replies. More often than not people end up using the telephone or meeting in person which wastes even more time rather than learning how to be clear. I don't understand why all effort to be clear and precise goes out of the window when dealing with email.
Well, then, your email client is crap? E-Mail has all the headers you need, and mutt, for example, does it perfectly.
I do a similar thing, but using mbsync to save into maildir. That way it's a simple cron job/systemd service to do the fetching, and Emacs/mutt/whatever can read the data without needing a server process to be running.
I used to use Gnus, but since it does everything in elisp it makes Emacs freeze :(
I now use mu4e, which uses an external command (mu) to query the maildir, so emacs remains responsive. My mail-fetching script also runs mu after mbsync's finished, to index any new messages.
Do you mean as opposed to putting the previous message on the top, or not including the previous message at all?
If I know my conversation is intended to a small group I'll reply inline, but my default is quote-on-top.
That brings up another point about using email for group conversations. If organizations hosted their own NNTP servers and commonly installed email clients also supported communication via NNTP, then this wouldn't be a problem. All messages already posted to a group would be visible to anyone who joins it at a later time. That's not the case with an email discussion that gets Cc'd to someone at a later time (since they don't have any of the earlier messages in their mailbox).
https://books.google.co.uk/books?id=C5-l28dcz50C&pg=PA186&lp...
(if the link doesn't work, search for NNTP Lotus Notes)
There is a MIME type for emails, so you can attach emails to emails, retaining their identity as emails, so the receiving MUA can display the emails you receive as an attachment just like any other emails, including the user interface for replying to them, or whatever.
Also, there is threading information in email headers. So, it is actually trivial to just gather together all the emails belonging to a specific conversation and attaching them all to an email to a third party that needs the history.
Using this bottom full quote nonsense is about as sensible as attaching a screen shot of a word document or something.
And all the idiots who followed blindly.
In addition to the obvious idiocy of sending someone a copy of what they just sent you ... I think it's funny to realize how this behaviour actually has quadratic space and bandwidth complexity:
If a thread is 10 message long, you have to store and transmit the data of 55 messages.
If a thread is 100 message long, you have to store and transmit the data of 5050 messages.
Or in general, if a thread is n message long, you have to store and transmit the data of n*(n+1)/2 messages.
Dozens of times a day I add someone to the cc list when I'm replying to an email. I suspect most people that have an assistant (or are one, or collaborate with others in general) do this constantly.
It's an incredibly common use case. Should we all abandon this very common behavior in order to avoid your scorn?
Incidentally, your daily dosage coincides with the amount of times I've had to do the same thing at all since I started using email some twenty five years ago.
> It's an incredibly common use case
For some, perhaps. On the other hand, I'd suggest that another, at least for me more common use case is to know exactly what is being replied to. Which is possible with proper quoting, rather than the let's-just-slap-on-your-entire-message-at-the-bottom-and-hope-you're-a-mind-reader nonsense.
1) Hi there I have a request for a meeting or phone call, or need something from your organization.
2) Great, I'm copying my assistant who will schedule this, or the other person in the company who knows the answer to your question, who I have now handed this task off to nearly instantly and seamlessly.
OTOH, inline quoting was always destined to fail. It requires that you purposefully and carefully edit and reply in the appropriate places. That's asking too much of the vast majority of people. B
OTOH, inline quoting was always destined to fail. It requires that one purposefully and carefully edit the thread and reply in the appropriate place. That's asking too much of the vast majority of people. Perhaps it could have been preserved to a greater extent had Microsoft Outlook not effectively forced bottom quoting, but alas that ship sailed decades ago.
--
A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?
A: Top-posting.
Q: What is the most annoying thing on usenet and in email?This is a great strategy for protecting yourself in business, but it makes everything slower and more difficult for everyone else.
Yup. I believe you've reinforced my point.
Not always. Sometimes it's just easier to communicate the context by just copying them the thread. It might lead to shorter mails and less explaining.
I do inline replies and all, but I still leave the quoted rest of the thread at the end of the message. If the recipient doesn't need it, they are free to ignore it. If the recipient needs it, then it's there. Many people don't use threaded email clients, or don't have access to the previous messages for whatever reason, and I don't want to second-guess how my recipient does things.
As long as it's clear where my reply ends and that there's nothing hidden at the end of the quoted previous messages, I really don't see the harm.
(About bandwidth or storage costs: they are negligible, and I do not think it is a good usage of time to worry about them.)
I always like Pine/Alpine. I only moved to Thunderbird, which is buggy and a resource hog, after I had to handle a dozen email accounts.
Question: How are many POP/IMAP accounts are currently handled under Pine/Alpine? Possible?
I've had some issues with how Alpine handles connection time outs though, as it annoyingly blocks the UI from time to time. Need to look further into this...