I use Emacs heavily, write projects in emacs lisp, and have used gnus and offlineimap/dovecot for my email for a year or so.<p>For nearly everyone this is a spectacularly bad idea, other than to gain some experience with Linux/Unix administration/configuration/infrastructure.<p>You will waste a LOT of time getting it set up and fiddling with it. It's pretty funny that the second heading in the article is titled "Fewer Distractions".<p>Just use Gmail and spend the time on something more worthwhile. The die-hards who still, in 2020, complain about HTML email are just wrong and absurd. Contrary to what they say, HTML email is very useful for discussing code: e.g. the ability to send well-presented syntax-highlighted code fragments for discussion is helpful, not a hindrance.<p>Really, I feel the same way about projects that insist on doing development by email. There was an appallingly arrogant and ignorant comment on emacs-devel the other day about how much superior Emacs' development practices are to the "entitled kids on GitHub" who just "shoot off a PR" and say "here it is can you check it in".<p>Just use PRs and just use cloud-hosted HTML email via a web client and get on with important things, and enjoy the new technology.
Emacs was Amazon's first Customer Service email system:<p>"Shel wrote Mailman in C, and Customer Service wrapped it in Lisp. Emacs-Lisp [...] Mailman was the Customer Service customer-email processing application for ... four, five years? A long time, anyway. It was written in Emacs. Everyone loved it."<p><a href="https://sites.google.com/site/steveyegge2/tour-de-babel" rel="nofollow">https://sites.google.com/site/steveyegge2/tour-de-babel</a><p>Ironically, while I was searching for that anecdote I happened upon this gem about a successor system:<p>"I'm only a humble customer service representative in Amazon, I really hate the email editor we use to mail the clients after they call or chat with us. This, of course, means I need to include Emacs on my workflow so I can suffer less, let's Elisp the heck out of this problem!"<p><a href="https://devrant.com/rants/520714/im-only-a-humble-customer-service-representative-in-amazon-i-really-hate-the-ema" rel="nofollow">https://devrant.com/rants/520714/im-only-a-humble-customer-s...</a>
I have used Emacs as my e-mail client for two decades now, namely Gnus. Gnus is no longer the best choice for many people, inasmuch as few still use Usenet (Gnus was conceived primarily as a newsreader), and you can get RSS feeds through the much more straightforward Emacs package Elfeed. If all one is using Gnus for is e-mail, then Gnus is slow and overcomplicated.<p>I myself thought about switching to Notmuch. The problem is that after 20 years, Gnus’s key bindings are burned into my muscle memory. It feels like it would be more hassle to switch to a different package and learn its interface than continue to use Gnus with all its flaws. Others here may have their own Emacs packages that they feel they can’t switch away from because these packages are so second-nature to them.
> I cringe everytime I see an email written in rich text with broad lines going well over 150 characters.<p>But you do understand that most of e-mail readers can do soft-wrapping, so you can choose when to soft break the line?<p>Because if not, you need to learn about it. If you hard wrap your emails at 80 characters, your e-mail will be unreadable on my phone.
I'm surprised MH-E hasn't been mentioned. (MH was mentioned in past tense.)<p>I have a whole system built on top of it. See
<a href="https://github.com/e40/emacs-mail-client" rel="nofollow">https://github.com/e40/emacs-mail-client</a><p>EDIT: I've been using MH-E to read email since the 80's.
Some people are discussing that receiving HTML emails Emacs doesn’t work well.<p>Here’s a blog post and video showing that it does, indeed, work very well: <a href="https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_emails_even_with_html.html" rel="nofollow">https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_e...</a><p>Source: I wrote the article and have used Emacs for email many years.
These days HTML mail is commonplace. I tried Emacs and mu4e thinking that because Emacs can display images (I’ve used it in org mode) it might have an acceptable way to display HTML mail. But I couldn’t make this work in any way that was palatable.<p>Years ago (maybe ten?) I used Mutt. Back then plain-text mail was more common, and when I got HTML mail, I could dump it out to plain text and get something useful. Now, most email authors assume your reader can render HTML. Often there is a plain-text part and all it will say is “you must enable HTML to read this mail.” Good grief it would be better if they’d just omit the plain text altogether if that’s all they’ll say.<p>Unfortunately the days of terminal-based email reading are over I’m afraid. At least some of the modern MUAs are sensitive to having good key bindings, including the MUAs like Gmail and Fastmail that run entirely in browsers.
Anyone remember Pine? Now, that was an email client. [1]<p>[1] <a href="https://en.wikipedia.org/wiki/Pine_%28email_client%29" rel="nofollow">https://en.wikipedia.org/wiki/Pine_%28email_client%29</a>
Emacs was one of my first email clients. It was great when email was largely plain text, and IMAP was still rare. Both MH and Gnus were fantastic. HTML email killed Emacs as a mail client for me.
I don't get this premise to try and cram tools with sleek powerful interfaces into limited old tools such as terminals and emacs. Don't get me wrong, I spend a lot of time in terminals and have a zshrc and tmux conf built up over many years, but I use them where they are best used - interacting with my local or a remote OS.
I'd love to do this again, but my company uses o365 and will not enable IMAP. Do any of the common background sync apps like mbsync or offlineimap support this now?
I used to use VM and Gnus heavily in Emacs, with lots of customizations. I hope to someday move back something like that, because it's just more productive than Thunderbird (and better than various mobile clients, and vastly better than the GMail UI).<p>Ideally, I'd like to make/use a mail client both very extensible (like we had in Emacs-based ones), and unusually secure from the start (more secure than even Claws can be). There are grander schemes I imagine this fitting into, but a better traditional mail client alone is a great first start.<p>You can see the approximate day I regretfully moved away from Emacs VM email, due to this data conversion script: <a href="https://www.neilvandyke.org/bbdb2tbird/" rel="nofollow">https://www.neilvandyke.org/bbdb2tbird/</a>
I used to use emacs for, well, everything, but email in particular. I've never felt more productive. So what changed?<p>Smartphones: with a smartphone becoming more and more of my life, I wanted my information synced across devices. In the early days of smartphones, this was challenging. It became easier to work with clients and systems that had the idea of accessing data from anywhere baked in.<p>Emacs threading: In an effort to keep emacs as my client, I switch from pop3 to imap, but let's be honest, it's a pain for emacs. To do it right, you need a local imap server and then sync between that and your remote imap and even then, emacs hangs as it connects and syncs new email. The lack of real multithreading for emacs really holds it back.
What are the security considerations of living in Emacs? Web browsers have battle tested sandboxes, and using individual native applications for everything leverages your platform's process model.