13 ms·

Emacs as Email Client

121 points by yannikyeo 6y ago

anotheryou 6y ago
I'm scared to jump in the water, I might like it.
- mycpuorg 6y ago
  Sounds like you will :)
- ReneFroger 6y ago
  You can take a look on http://emacs.zeef.com/ http://emacs.zeef.com/ It's a good starting point for your rabbit hole into Emacs.
- eeh 6y ago
  I can't say for sure that the time I've spent working with Emacs has been overall net positive, but I enjoy it, and it's changed how I think about the interface between users and their programs.
prosody 6y ago
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.
- mycpuorg 6y ago
  Not sure I understand your question, but in general rich web experience is close to 0. I use html2text which is good for the most part but if you receive emails with embedded javascript and you want to avoid them (a lot of phishing traps goes out of the equation with plaintext). It's a matter of your personal preference and priority. If you like the sort of things mentioned in the article you should give it a shot, at least, try taking a 2-week sabbatical from web email.
  - deleted 6y ago
    [deleted]
  - wahern 6y ago
    Are there any e-mail clients that actually execute JavaScript? I use mutt, Mail.app, and occasionally GMail, and none even support JavaScript execution, AFAIK, let alone execute it by default.
    - mycpuorg 6y ago
      Granted. I am not equipped to answer the question, assumption about js could be wrong too. Perhaps, I should replace javascript with HTML. The argument still holds about distractions and phishing risks etc.
- WhatIsDukkha 6y ago
  I think the security issues are potentially pretty significant. It's a garbage collected language with parsers that have been run a few millions times so its not new code but... I generally don't do much network anything except across secure lan. I personally think using Emacs for irc or chat is bananas. Emacs can be sandboxed but mostly isn't as people do so much with it and the current model is for a single main process usually. It could evolve though and I think its inevitable that it will. Fwiw I think not just Emacs but all the ditors are more at risk from supplychain attacks and build scripts from the internet. We'll see.
  - metroholografix 6y ago
    Why is using Emacs for IRC bananas? What do you think can happen? Give me something concrete, not vague assertions. You can spend less than 5 minutes looking over the source of RCIRC (rcirc.el, written in Emacs Lisp) where it's crystal clear that you can't have remote code execution in that Emacs Lisp code.
    - WhatIsDukkha 6y ago
      Five minutes might tell you there is no (eval) in the path but I don't see how thats useful.
      - metroholografix 6y ago
        It's useful in that it demonstrates a reduced attack surface. You can immediately see that there are no command injection possibilities. Additionally, there is no potential for integer overflows, memory corruption, undefined behavior, compiler optimizing your safety checks away and so on. A parser bug in Emacs Lisp will signal an error inside Emacs which will end up in either a debugger popup buffer or a message in * Messages*. So using Emacs for IRC is pretty much the same order of bananas as using a .NET or Java client. Do you think that's bananas too?
        WhatIsDukkha 6y ago
- metroholografix 6y ago
  Modern web browsers expose an enormous attack surface with a gazillion parsers written in C and C++. They are also constant targets due to marketshare and ease/flexibility of payload delivery. Emacs is written mostly in Emacs Lisp, a memory safe language. So security implications come down to either logic bugs, the C parts of Emacs or the C libraries, usually parsers, that Emacs links with (e.g. ImageMagick which should never be enabled by security-conscious folks and GnuTLS which Emacs supports using out-of-process and security-conscious folks that need it should do so). Let's look at some published vulnerability statistics. Google Chrome: > 550 total, 121 remotely exploitable code execution, 450+ memory corruption/overflows (potentially exploitable). Emacs: 0 unassisted remotely exploitable code exec vulnerabilities, 2 assisted ones (CVE-2017-14482, CVE-2012-3479). Finally, note how specific to exact requirements the Emacs vulnerabilities are. You had to either read an email sent to you containing the payload or open a plain text file with the payload embedded in it and clearly visible. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-741/GNU-Emacs.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... [2] https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 https://www.cvedetails.com/product/15031/Google-Chrome.html?...
  - WhatIsDukkha 6y ago
    I don't totally disagree with you but- I'm not aware of any serious bugbounty programs for Emacs. Emacs exploits would be immensely valuable in the right contexts.
  - oblio 6y ago
    Chrome probably has 1 (2?) billion users. Emacs has what? 100k at best? The financial incentive to attack Chrome is much, much higher.
jaaron 6y ago
I used to use emacs for, well, everything, but email in particular. I've never felt more productive. So what changed? 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. 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.
- ssivark 6y ago
  For regular syncing, if one runs mbsync/etc as a cron/systemd task, rather than triggering it through Emacs, then the locking problem should be avoided.
- Mediterraneo10 6y ago
  Smartphones feel like an example of where we have really gone backwards. Ten years ago you could get a Nokia N900 with its hardware keyboard, and it was entirely comfortable to check my e-mail by SSHing from the N900 to my home computer which was running Emacs server and to which my e-mail was downloaded (as POP3, so no hanging like IMAP).
  - oblio 6y ago
    > Smartphones feel like an example of where we have really gone backwards. For techies, which are something like 1-5% of the population. For everyone else, for grandpa and grandma, smartphones are a giant leap forward.
    - Mediterraneo10 6y ago
      This is a forum by techies for techies. Was it really necessary to spell this out?
satya71 6y ago
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.
- jaaron 6y ago
  Yes. I really miss it, but I'm just not sure how practical it is anymore.
  - mycpuorg 6y ago
    Hi, author of the blog here. It is not everything, but if you were optimizing for certain things like less distraction, fewer "fire fighting threads", detailed thoughts shared via email then Emacs is great. I have learnt to live in plain text for a while now and it is great because a lot the cases don't really require you to respond in html. If you are doing it often, it's probably worth attaching a 2-pager. But if you are in a, say consultant role, where quicker email responses to clients, html support, MS Word like highlighting, then this is not it.
    - jaaron 6y ago
      I'm honestly envious and this has me thinking about how I can move some of my workflow back into emacs because I do think it was more sane. Definitely allowed for more deep work. I know, for some folks not already familiar with emacs that can sound crazy, but I've already invested in the learning curve.
      - mycpuorg 6y ago
        True. I think the workflow will continue to be fragmented even with richer email content.
  - truncate 6y ago
    Speaking of practical, I really like GMail interface. Their system of tagging over folder really work well for me (I think there are CLI alternatives to do so). But more recently, I'm pretty addicted to using the AI suggestions that GMail gives when composing an email.
bojo 6y ago
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?
- buster 6y ago
  Look up davmail. It proxies o365 to imap/smtp/caldav/carddav. I'm using it with offlineimap.
dpcx 6y ago
"Every program attempts to expand until it can read mail"
- mycpuorg 6y ago
  Wow! Source?
  - moioci 6y ago
    https://en.wikipedia.org/wiki/Jamie_Zawinski https://en.wikipedia.org/wiki/Jamie_Zawinski
  - Slackwise 6y ago
    This is known as Zawinski's Law[1]: https://www.jwz.org/hacks/#:~:text=Law%20of%20Software%20Envelopment https://www.jwz.org/hacks/#:~:text=Law%20of%20Software%20Env... [1]: Zawinski as in "jwz", Jamie Zawinksi: https://www.jwz.org/about.html https://www.jwz.org/about.html
    - hornetblack 6y ago
      Uhhh. jwz.org checks the referer header for hacker news and redircts to a picture of some male gentailia in a egg cup, with some text of what jwz thinks of this site. I'd advise linking to a archive.org version of the url.
      - Slackwise 6y ago
        Uhhhhhhhhhhhhhhh, alrighty then........ can't edit or even delete now. Thanks for the heads-up.... (Mods, could you change it if you see this?!)
- HerrMonnezza 6y ago
  I am pretty sure Emacs could already read and send email by the time JWZ formulated this law...
  - 6y ago
pbourke 6y ago
Emacs was Amazon's first Customer Service email system: "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." https://sites.google.com/site/steveyegge2/tour-de-babel https://sites.google.com/site/steveyegge2/tour-de-babel Ironically, while I was searching for that anecdote I happened upon this gem about a successor system: "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!" https://devrant.com/rants/520714/im-only-a-humble-customer-service-representative-in-amazon-i-really-hate-the-ema https://devrant.com/rants/520714/im-only-a-humble-customer-s...
- PaulDavisThe1st 6y ago
  That blog post is incorrect. Mailman was written in C++, like all the early code at Amazon, but Shel and I decided to limit the C++ features we would use to a very small set. More like "C with classes". It was still C++ and it would not have compiled with a C compiler. It goes even "wronger": >Shel, Eric, Greg, and others like them that I wasn't fortunate enough to work with directly: they didn't allow C++ here, and they didn't allow Perl. We explicitly made the choice to use C++ (with the proviso mentioned above). We used Perl for a variety of tasks. Likely some of those choices were modified later, but it is incorrect to ascribe the "no C++" rule back to Shel and the beginning of Amazon, because the opposite is true. Source: Shel was employee #1, I was employee #2.
  - DonHopkins 6y ago
    Ha ha! Was "C with classes" influenced by ScriptX's "OIC" ("Objects in C"), which Shel Kaphan and Eric Benson worked on at Kaleida Labs? https://en.wikipedia.org/wiki/Kaleida_Labs https://en.wikipedia.org/wiki/Kaleida_Labs https://en.wikipedia.org/wiki/ScriptX https://en.wikipedia.org/wiki/ScriptX http://www.art.net/~hopkins/Don/lang/scriptx/tech-qa.html#oic http://www.art.net/~hopkins/Don/lang/scriptx/tech-qa.html#oi... >Q: What is Objects In C? >A: Objects in C (OIC) is a suite of function, macro, and class libraries that provide the object model used by ScriptX. OIC is modeled on CLOS, the ANSI standard LISP object-oriented programming system and supports capabilites such as dynamic types, global polymorphism, and dynamic method redirection. >OIC only requires an ANSI C compiler, which makes it highly portable. >Both ScriptX and the Kaleida Media Player are written in OIC. https://www.linkedin.com/in/shelkaphan/ https://www.linkedin.com/in/shelkaphan/ Shel Kaphan Principal Engineer Company Name: Kaleida Labs Dates Employed: Sep 1992 – Jun 1994 Employment Duration: 1 yr 10 mos Wrote a persistent object system for ScriptX, Kaleida's multi-media authoring language. ScriptX also influenced the "MAXScript" scripting language in 3D Studio MAX, which was developed by John Wainwright, one of the other architects of Kaleida ScriptX, and designer of "Objects in C". https://www.linkedin.com/in/john-wainwright-870110/ https://www.linkedin.com/in/john-wainwright-870110/ John Wainwright Chief Architect and Principal Engineer Company Name: Kaleida Labs Dates Employed: 1992 – 1996 Employment Duration: 4 yrs Negotiated the sale of Objects-in-C to Apple and Kaleida Labs, which was then adopted as the underlying object system for ScriptX. Responsible for further design and implementation of the object system. Within 6 months, assumed overal architectural responsibility for ScriptX and was the principal designer of the language and implemented the bytecode interpreter and other runtime system components. John went on to independently develop MAXScript for 3D Studio MAX, which he then sold to Autodesk, who built it in as the official MAX scripting language. Consultant Company Name: Autodesk Dates Employed: 1996 – 2000 Employment Duration: 4 yrs Location: Silicon Valley Independently developed MAXScript, a scripting language for Autodesk's 3D Studio MAX, the leading 3D modelling and animation product. I negotiated the sale of MAXScript to Autodesk for adoption as the core scripting language and continued development of MAXScript under consulting contract to Autodesk through 3 major releases. I migrated to core 3ds MAX development, re-architected the internal object model for enhanced scriptability and added several new features including the parameter-wiring based animation system. I also developed a 3D camera motion tracking system for 3D Studio MAX, presented talks and seminars on MAXScript at several successive SIGGRAPH conferences. I was awarded four patents in the area of 3D animation as inventor on behalf of Autodesk, Inc. MaxScript was a lot like ScriptX in many ways, and I enjoyed using both languages, which were pleasantly Lispy! After working on ScriptX at Kaleida, I used MAXScript at Maxis to develop the exporter and content pipeline for the character animation system in The Sims. Automating The Sims Character Animation Pipeline with MaxScript https://medium.com/@donhopkins/automating-the-sims-character-animation-pipeline-with-maxscript-bc490787d7a2 https://medium.com/@donhopkins/automating-the-sims-character...
Mediterraneo10 6y ago
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. 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.
- jiveturkey 6y ago
  same. i was a huge Gnus user. the combination of email and usenet was nice. a bygone era.
- da39a3ee 6y ago
  Do you think it's maybe time to move Gnus out of the Emacs core distribution and maintain it as a package in ELPA? It feels wrong to me to be maintaining so much unnecessary code in the core distribution.
  - Mediterraneo10 6y ago
    No. The core distribution isn't that big, and I like how it contains features that harken back to an earlier era – it acts as a sort of history museum on matters that younger programmers might like to learn about.
    - db48x 6y ago
      It's well over a million lines of elisp, which is not small. But it's certainly not much disk space.
  - girzel 6y ago
    Gnus only got moved into Emacs core a couple of years ago. Lars got tired of supporting fourteen different Emacs versions, including XEmacs, and finally just tied it to core. The ELPA package repository is developing the concept of core-but-installable, whereby a package is shipped with core, but a newer version can be installed via ELPA, and that might be a viable path for Gnus. I don't think the issue was needing Gnus in core, so much as it was avoiding all the multi-version support headache. But one could simply declare that the package is only supported for the two most recent Emacs versions, for instance, and call it good.
_emacsomancer_ 6y ago
Email is a big part of my job. Emacs makes that part of my job somewhat more bearable, and much faster.
da39a3ee 6y ago
I use Emacs heavily, write projects in emacs lisp, and have used gnus and offlineimap/dovecot for my email for a year or so. For nearly everyone this is a spectacularly bad idea, other than to gain some experience with Linux/Unix administration/configuration/infrastructure. 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". 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. 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". 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.
- outworlder 6y ago
  > 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. > Really, I feel the same way about projects that insist on doing development by email. Wait. HTML email is useful for reviewing code, but you don't like when code reviews are done over email? Which is it? I see no reason for HTML email to exist, but I've stopped trying to fight that. Emacs is far superior to any email client for editing text. And so is VI for that matter. I've used a setup to send emails from Emacs (but not receive/view them). For that, Mutt and something like Notmuch are far more useful. Even today, even though I mostly use Outlook (because management, I have no excuse if I miss a meeting because my client didn't properly parse the Outlook invite), I still find it useful to compose long emails in Emacs and then just paste them on the editor. I do agree that a full email setup on Emacs can be a waste of time for most people.
  - 6y ago
massysett 6y ago
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. 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. 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.
- preek 6y ago
  Receiving HTML mails work fine in Emacs, too: https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_emails_even_with_html.html https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_e...
e40 6y ago
I'm surprised MH-E hasn't been mentioned. (MH was mentioned in past tense.) I have a whole system built on top of it. See https://github.com/e40/emacs-mail-client https://github.com/e40/emacs-mail-client EDIT: I've been using MH-E to read email since the 80's.
- DonHopkins 6y ago
  Or RMAIL or BABYL! https://www.emacswiki.org/emacs/Babyl https://www.emacswiki.org/emacs/Babyl >BABYL is the name of an e-mail package created under ITS at the MIT AI Lab, written in TECO. It was a replacement for an earlier package called RMAIL. BABYL is still available under ITS and TOPS-20 (a DEC development of the TENEX operating system) both on real hardware and under the KLH10 and SimH emulators of the PDP-10 processor. The original RMAIL was restricted to ITS, and the source code was typically located in EMACS1;RMAILX >. >The internal format of BABYL mailbox files was retained when GNU Emacs was created, even though the facility was renamed “RMail”. Lovely TECO RMAIL source code: https://github.com/PDP-10/its/blob/4e2ea8e4d851a0ea1f910c3001e5c2ddb9ff528c/src/emacs1/rmailx.1 https://github.com/PDP-10/its/blob/4e2ea8e4d851a0ea1f910c300... Oops, silly GitHub thinks TECO source code looks like a binary file! What are a few control characters between friends? Here it is as text (and quoted with escapes and control characters transliterated to ^[ etc.): https://donhopkins.com/home/code/teco/rmailx.1.txt https://donhopkins.com/home/code/teco/rmailx.1.txt !Re edit! 0U..H !* MAKE DISPLAY OCCUR?! [..J :I..JRMAIL-Mail^[ FSRGETTY^["E FT ^[ B,.T FT^[..A^[ .,ZT' !* give printing lusers some hope! ^R ]..J !* LET USER TYPE HIS REPLY IN! Q..0&337.-307."E ^\' Z"E ^\' !* IF HE DIDNT EXIT WITH ^G, AND DIDNT CLEAR THE BUFFER,! 1:< M(M.M &_Mail_Buffer^[)>F"E W^\' !* Mail the contents. Error => go back to editing. ! @:FG O Re edit^[ Aaaah, classic TECO, so well commented, elegantly indented, and easy on the eyes!
  - perl4ever 6y ago
    Makes INTERCAL look kind of bland and unimaginative.
- housel 6y ago
  I also used MH-E in the 80s. Around the turn of the century I switched to Wanderlust (https://github.com/wanderlust/wanderlust https://github.com/wanderlust/wanderlust), since it could handle IMAP as well as interoperate with MH maildirs. It's not my primary e-mail client, but it is able to share my personal IMAP server with all of the other e-mail clients I use.
taude 6y ago
Anyone remember Pine? Now, that was an email client. [1] [1] https://en.wikipedia.org/wiki/Pine_%28email_client%29 https://en.wikipedia.org/wiki/Pine_%28email_client%29
- cylinder714 6y ago
  Yup! Loved it, but I haven't tried Alpine, its successor, yet. I used it on a Windows 2000 box along with Vim 7.x and a copy of the excellent Par paragraph formatter (http://www.nicemice.net/par/ http://www.nicemice.net/par/) that someone had kindly ported to Windows. That combination made email on Windows tolerable for this Unix-Xenix hand. And before that, I supported Z-Mail on various platforms, but was the go-to guy for the terminal-based version, the fastest version we produced.
  - taude 6y ago
    If email were still my main communication at work (it's now Slack), I'd seriously look into Alpine, I had no idea that Pine went to live on in spirit.
neilv 6y ago
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). 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. You can see the approximate day I regretfully moved away from Emacs VM email, due to this data conversion script: https://www.neilvandyke.org/bbdb2tbird/ https://www.neilvandyke.org/bbdb2tbird/
- neilv 6y ago
  When email providers were tacking garish ads onto emails from our friends, the easy extensibility of Emacs made it easy to add email ad blocking. :) https://www.neilvandyke.org/sigbegone/ https://www.neilvandyke.org/sigbegone/
preek 6y ago
Some people are discussing that receiving HTML emails Emacs doesn’t work well. Here’s a blog post and video showing that it does, indeed, work very well: https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_emails_even_with_html.html https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_e... Source: I wrote the article and have used Emacs for email many years.
cachestash 6y ago
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.
self_awareness 6y ago
> I cringe everytime I see an email written in rich text with broad lines going well over 150 characters. But you do understand that most of e-mail readers can do soft-wrapping, so you can choose when to soft break the line? 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.
- preek 6y ago
  I agree on what you said. Having said that, there’s no need to hard wrap using Emacs. Format flowed works just as well as in other MUAs.

121 points by yannikyeo 6y ago

anotheryou 6y ago

I'm scared to jump in the water, I might like it.

mycpuorg 6y ago
Sounds like you will :)
ReneFroger 6y ago
You can take a look on http://emacs.zeef.com/ http://emacs.zeef.com/ It's a good starting point for your rabbit hole into Emacs.
eeh 6y ago
I can't say for sure that the time I've spent working with Emacs has been overall net positive, but I enjoy it, and it's changed how I think about the interface between users and their programs.

prosody 6y ago

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.

mycpuorg 6y ago
Not sure I understand your question, but in general rich web experience is close to 0. I use html2text which is good for the most part but if you receive emails with embedded javascript and you want to avoid them (a lot of phishing traps goes out of the equation with plaintext). It's a matter of your personal preference and priority. If you like the sort of things mentioned in the article you should give it a shot, at least, try taking a 2-week sabbatical from web email.
- deleted 6y ago
  [deleted]
- wahern 6y ago
  Are there any e-mail clients that actually execute JavaScript? I use mutt, Mail.app, and occasionally GMail, and none even support JavaScript execution, AFAIK, let alone execute it by default.
  - mycpuorg 6y ago
    Granted. I am not equipped to answer the question, assumption about js could be wrong too. Perhaps, I should replace javascript with HTML. The argument still holds about distractions and phishing risks etc.
WhatIsDukkha 6y ago
I think the security issues are potentially pretty significant. It's a garbage collected language with parsers that have been run a few millions times so its not new code but... I generally don't do much network anything except across secure lan. I personally think using Emacs for irc or chat is bananas. Emacs can be sandboxed but mostly isn't as people do so much with it and the current model is for a single main process usually. It could evolve though and I think its inevitable that it will. Fwiw I think not just Emacs but all the ditors are more at risk from supplychain attacks and build scripts from the internet. We'll see.
- metroholografix 6y ago
  Why is using Emacs for IRC bananas? What do you think can happen? Give me something concrete, not vague assertions. You can spend less than 5 minutes looking over the source of RCIRC (rcirc.el, written in Emacs Lisp) where it's crystal clear that you can't have remote code execution in that Emacs Lisp code.
  - WhatIsDukkha 6y ago
    Five minutes might tell you there is no (eval) in the path but I don't see how thats useful.
    - metroholografix 6y ago
      It's useful in that it demonstrates a reduced attack surface. You can immediately see that there are no command injection possibilities. Additionally, there is no potential for integer overflows, memory corruption, undefined behavior, compiler optimizing your safety checks away and so on. A parser bug in Emacs Lisp will signal an error inside Emacs which will end up in either a debugger popup buffer or a message in * Messages*. So using Emacs for IRC is pretty much the same order of bananas as using a .NET or Java client. Do you think that's bananas too?
      - WhatIsDukkha 6y ago
metroholografix 6y ago
Modern web browsers expose an enormous attack surface with a gazillion parsers written in C and C++. They are also constant targets due to marketshare and ease/flexibility of payload delivery. Emacs is written mostly in Emacs Lisp, a memory safe language. So security implications come down to either logic bugs, the C parts of Emacs or the C libraries, usually parsers, that Emacs links with (e.g. ImageMagick which should never be enabled by security-conscious folks and GnuTLS which Emacs supports using out-of-process and security-conscious folks that need it should do so). Let's look at some published vulnerability statistics. Google Chrome: > 550 total, 121 remotely exploitable code execution, 450+ memory corruption/overflows (potentially exploitable). Emacs: 0 unassisted remotely exploitable code exec vulnerabilities, 2 assisted ones (CVE-2017-14482, CVE-2012-3479). Finally, note how specific to exact requirements the Emacs vulnerabilities are. You had to either read an email sent to you containing the payload or open a plain text file with the payload embedded in it and clearly visible. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-741/GNU-Emacs.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... [2] https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 https://www.cvedetails.com/product/15031/Google-Chrome.html?...
- WhatIsDukkha 6y ago
  I don't totally disagree with you but- I'm not aware of any serious bugbounty programs for Emacs. Emacs exploits would be immensely valuable in the right contexts.
- oblio 6y ago
  Chrome probably has 1 (2?) billion users. Emacs has what? 100k at best? The financial incentive to attack Chrome is much, much higher.

jaaron 6y ago

I used to use emacs for, well, everything, but email in particular. I've never felt more productive. So what changed? 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. 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.

ssivark 6y ago
For regular syncing, if one runs mbsync/etc as a cron/systemd task, rather than triggering it through Emacs, then the locking problem should be avoided.
Mediterraneo10 6y ago
Smartphones feel like an example of where we have really gone backwards. Ten years ago you could get a Nokia N900 with its hardware keyboard, and it was entirely comfortable to check my e-mail by SSHing from the N900 to my home computer which was running Emacs server and to which my e-mail was downloaded (as POP3, so no hanging like IMAP).
- oblio 6y ago
  > Smartphones feel like an example of where we have really gone backwards. For techies, which are something like 1-5% of the population. For everyone else, for grandpa and grandma, smartphones are a giant leap forward.
  - Mediterraneo10 6y ago
    This is a forum by techies for techies. Was it really necessary to spell this out?

satya71 6y ago

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.

jaaron 6y ago
Yes. I really miss it, but I'm just not sure how practical it is anymore.
- mycpuorg 6y ago
  Hi, author of the blog here. It is not everything, but if you were optimizing for certain things like less distraction, fewer "fire fighting threads", detailed thoughts shared via email then Emacs is great. I have learnt to live in plain text for a while now and it is great because a lot the cases don't really require you to respond in html. If you are doing it often, it's probably worth attaching a 2-pager. But if you are in a, say consultant role, where quicker email responses to clients, html support, MS Word like highlighting, then this is not it.
  - jaaron 6y ago
    I'm honestly envious and this has me thinking about how I can move some of my workflow back into emacs because I do think it was more sane. Definitely allowed for more deep work. I know, for some folks not already familiar with emacs that can sound crazy, but I've already invested in the learning curve.
    - mycpuorg 6y ago
      True. I think the workflow will continue to be fragmented even with richer email content.
- truncate 6y ago
  Speaking of practical, I really like GMail interface. Their system of tagging over folder really work well for me (I think there are CLI alternatives to do so). But more recently, I'm pretty addicted to using the AI suggestions that GMail gives when composing an email.

bojo 6y ago

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?

buster 6y ago
Look up davmail. It proxies o365 to imap/smtp/caldav/carddav. I'm using it with offlineimap.

dpcx 6y ago

"Every program attempts to expand until it can read mail"

mycpuorg 6y ago
Wow! Source?
- moioci 6y ago
  https://en.wikipedia.org/wiki/Jamie_Zawinski https://en.wikipedia.org/wiki/Jamie_Zawinski
- Slackwise 6y ago
  This is known as Zawinski's Law[1]: https://www.jwz.org/hacks/#:~:text=Law%20of%20Software%20Envelopment https://www.jwz.org/hacks/#:~:text=Law%20of%20Software%20Env... [1]: Zawinski as in "jwz", Jamie Zawinksi: https://www.jwz.org/about.html https://www.jwz.org/about.html
  - hornetblack 6y ago
    Uhhh. jwz.org checks the referer header for hacker news and redircts to a picture of some male gentailia in a egg cup, with some text of what jwz thinks of this site. I'd advise linking to a archive.org version of the url.
    - Slackwise 6y ago
      Uhhhhhhhhhhhhhhh, alrighty then........ can't edit or even delete now. Thanks for the heads-up.... (Mods, could you change it if you see this?!)
HerrMonnezza 6y ago
I am pretty sure Emacs could already read and send email by the time JWZ formulated this law...
- 6y ago

pbourke 6y ago

Emacs was Amazon's first Customer Service email system: "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." https://sites.google.com/site/steveyegge2/tour-de-babel https://sites.google.com/site/steveyegge2/tour-de-babel Ironically, while I was searching for that anecdote I happened upon this gem about a successor system: "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!" https://devrant.com/rants/520714/im-only-a-humble-customer-service-representative-in-amazon-i-really-hate-the-ema https://devrant.com/rants/520714/im-only-a-humble-customer-s...

PaulDavisThe1st 6y ago
That blog post is incorrect. Mailman was written in C++, like all the early code at Amazon, but Shel and I decided to limit the C++ features we would use to a very small set. More like "C with classes". It was still C++ and it would not have compiled with a C compiler. It goes even "wronger": >Shel, Eric, Greg, and others like them that I wasn't fortunate enough to work with directly: they didn't allow C++ here, and they didn't allow Perl. We explicitly made the choice to use C++ (with the proviso mentioned above). We used Perl for a variety of tasks. Likely some of those choices were modified later, but it is incorrect to ascribe the "no C++" rule back to Shel and the beginning of Amazon, because the opposite is true. Source: Shel was employee #1, I was employee #2.
- DonHopkins 6y ago
  Ha ha! Was "C with classes" influenced by ScriptX's "OIC" ("Objects in C"), which Shel Kaphan and Eric Benson worked on at Kaleida Labs? https://en.wikipedia.org/wiki/Kaleida_Labs https://en.wikipedia.org/wiki/Kaleida_Labs https://en.wikipedia.org/wiki/ScriptX https://en.wikipedia.org/wiki/ScriptX http://www.art.net/~hopkins/Don/lang/scriptx/tech-qa.html#oic http://www.art.net/~hopkins/Don/lang/scriptx/tech-qa.html#oi... >Q: What is Objects In C? >A: Objects in C (OIC) is a suite of function, macro, and class libraries that provide the object model used by ScriptX. OIC is modeled on CLOS, the ANSI standard LISP object-oriented programming system and supports capabilites such as dynamic types, global polymorphism, and dynamic method redirection. >OIC only requires an ANSI C compiler, which makes it highly portable. >Both ScriptX and the Kaleida Media Player are written in OIC. https://www.linkedin.com/in/shelkaphan/ https://www.linkedin.com/in/shelkaphan/ Shel Kaphan Principal Engineer Company Name: Kaleida Labs Dates Employed: Sep 1992 – Jun 1994 Employment Duration: 1 yr 10 mos Wrote a persistent object system for ScriptX, Kaleida's multi-media authoring language. ScriptX also influenced the "MAXScript" scripting language in 3D Studio MAX, which was developed by John Wainwright, one of the other architects of Kaleida ScriptX, and designer of "Objects in C". https://www.linkedin.com/in/john-wainwright-870110/ https://www.linkedin.com/in/john-wainwright-870110/ John Wainwright Chief Architect and Principal Engineer Company Name: Kaleida Labs Dates Employed: 1992 – 1996 Employment Duration: 4 yrs Negotiated the sale of Objects-in-C to Apple and Kaleida Labs, which was then adopted as the underlying object system for ScriptX. Responsible for further design and implementation of the object system. Within 6 months, assumed overal architectural responsibility for ScriptX and was the principal designer of the language and implemented the bytecode interpreter and other runtime system components. John went on to independently develop MAXScript for 3D Studio MAX, which he then sold to Autodesk, who built it in as the official MAX scripting language. Consultant Company Name: Autodesk Dates Employed: 1996 – 2000 Employment Duration: 4 yrs Location: Silicon Valley Independently developed MAXScript, a scripting language for Autodesk's 3D Studio MAX, the leading 3D modelling and animation product. I negotiated the sale of MAXScript to Autodesk for adoption as the core scripting language and continued development of MAXScript under consulting contract to Autodesk through 3 major releases. I migrated to core 3ds MAX development, re-architected the internal object model for enhanced scriptability and added several new features including the parameter-wiring based animation system. I also developed a 3D camera motion tracking system for 3D Studio MAX, presented talks and seminars on MAXScript at several successive SIGGRAPH conferences. I was awarded four patents in the area of 3D animation as inventor on behalf of Autodesk, Inc. MaxScript was a lot like ScriptX in many ways, and I enjoyed using both languages, which were pleasantly Lispy! After working on ScriptX at Kaleida, I used MAXScript at Maxis to develop the exporter and content pipeline for the character animation system in The Sims. Automating The Sims Character Animation Pipeline with MaxScript https://medium.com/@donhopkins/automating-the-sims-character-animation-pipeline-with-maxscript-bc490787d7a2 https://medium.com/@donhopkins/automating-the-sims-character...

Mediterraneo10 6y ago

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. 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.

jiveturkey 6y ago
same. i was a huge Gnus user. the combination of email and usenet was nice. a bygone era.
da39a3ee 6y ago
Do you think it's maybe time to move Gnus out of the Emacs core distribution and maintain it as a package in ELPA? It feels wrong to me to be maintaining so much unnecessary code in the core distribution.
- Mediterraneo10 6y ago
  No. The core distribution isn't that big, and I like how it contains features that harken back to an earlier era – it acts as a sort of history museum on matters that younger programmers might like to learn about.
  - db48x 6y ago
    It's well over a million lines of elisp, which is not small. But it's certainly not much disk space.
- girzel 6y ago
  Gnus only got moved into Emacs core a couple of years ago. Lars got tired of supporting fourteen different Emacs versions, including XEmacs, and finally just tied it to core. The ELPA package repository is developing the concept of core-but-installable, whereby a package is shipped with core, but a newer version can be installed via ELPA, and that might be a viable path for Gnus. I don't think the issue was needing Gnus in core, so much as it was avoiding all the multi-version support headache. But one could simply declare that the package is only supported for the two most recent Emacs versions, for instance, and call it good.

_emacsomancer_ 6y ago

Email is a big part of my job. Emacs makes that part of my job somewhat more bearable, and much faster.

da39a3ee 6y ago

I use Emacs heavily, write projects in emacs lisp, and have used gnus and offlineimap/dovecot for my email for a year or so. For nearly everyone this is a spectacularly bad idea, other than to gain some experience with Linux/Unix administration/configuration/infrastructure. 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". 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. 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". 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.

outworlder 6y ago
> 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. > Really, I feel the same way about projects that insist on doing development by email. Wait. HTML email is useful for reviewing code, but you don't like when code reviews are done over email? Which is it? I see no reason for HTML email to exist, but I've stopped trying to fight that. Emacs is far superior to any email client for editing text. And so is VI for that matter. I've used a setup to send emails from Emacs (but not receive/view them). For that, Mutt and something like Notmuch are far more useful. Even today, even though I mostly use Outlook (because management, I have no excuse if I miss a meeting because my client didn't properly parse the Outlook invite), I still find it useful to compose long emails in Emacs and then just paste them on the editor. I do agree that a full email setup on Emacs can be a waste of time for most people.
- 6y ago

massysett 6y ago

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. 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. 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.

preek 6y ago
Receiving HTML mails work fine in Emacs, too: https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_emails_even_with_html.html https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_e...

e40 6y ago

I'm surprised MH-E hasn't been mentioned. (MH was mentioned in past tense.) I have a whole system built on top of it. See https://github.com/e40/emacs-mail-client https://github.com/e40/emacs-mail-client EDIT: I've been using MH-E to read email since the 80's.

DonHopkins 6y ago
Or RMAIL or BABYL! https://www.emacswiki.org/emacs/Babyl https://www.emacswiki.org/emacs/Babyl >BABYL is the name of an e-mail package created under ITS at the MIT AI Lab, written in TECO. It was a replacement for an earlier package called RMAIL. BABYL is still available under ITS and TOPS-20 (a DEC development of the TENEX operating system) both on real hardware and under the KLH10 and SimH emulators of the PDP-10 processor. The original RMAIL was restricted to ITS, and the source code was typically located in EMACS1;RMAILX >. >The internal format of BABYL mailbox files was retained when GNU Emacs was created, even though the facility was renamed “RMail”. Lovely TECO RMAIL source code: https://github.com/PDP-10/its/blob/4e2ea8e4d851a0ea1f910c3001e5c2ddb9ff528c/src/emacs1/rmailx.1 https://github.com/PDP-10/its/blob/4e2ea8e4d851a0ea1f910c300... Oops, silly GitHub thinks TECO source code looks like a binary file! What are a few control characters between friends? Here it is as text (and quoted with escapes and control characters transliterated to ^[ etc.): https://donhopkins.com/home/code/teco/rmailx.1.txt https://donhopkins.com/home/code/teco/rmailx.1.txt !Re edit! 0U..H !* MAKE DISPLAY OCCUR?! [..J :I..JRMAIL-Mail^[ FSRGETTY^["E FT ^[ B,.T FT^[..A^[ .,ZT' !* give printing lusers some hope! ^R ]..J !* LET USER TYPE HIS REPLY IN! Q..0&337.-307."E ^\' Z"E ^\' !* IF HE DIDNT EXIT WITH ^G, AND DIDNT CLEAR THE BUFFER,! 1:< M(M.M &_Mail_Buffer^[)>F"E W^\' !* Mail the contents. Error => go back to editing. ! @:FG O Re edit^[ Aaaah, classic TECO, so well commented, elegantly indented, and easy on the eyes!
- perl4ever 6y ago
  Makes INTERCAL look kind of bland and unimaginative.
housel 6y ago
I also used MH-E in the 80s. Around the turn of the century I switched to Wanderlust (https://github.com/wanderlust/wanderlust https://github.com/wanderlust/wanderlust), since it could handle IMAP as well as interoperate with MH maildirs. It's not my primary e-mail client, but it is able to share my personal IMAP server with all of the other e-mail clients I use.

taude 6y ago

Anyone remember Pine? Now, that was an email client. [1] [1] https://en.wikipedia.org/wiki/Pine_%28email_client%29 https://en.wikipedia.org/wiki/Pine_%28email_client%29

cylinder714 6y ago
Yup! Loved it, but I haven't tried Alpine, its successor, yet. I used it on a Windows 2000 box along with Vim 7.x and a copy of the excellent Par paragraph formatter (http://www.nicemice.net/par/ http://www.nicemice.net/par/) that someone had kindly ported to Windows. That combination made email on Windows tolerable for this Unix-Xenix hand. And before that, I supported Z-Mail on various platforms, but was the go-to guy for the terminal-based version, the fastest version we produced.
- taude 6y ago
  If email were still my main communication at work (it's now Slack), I'd seriously look into Alpine, I had no idea that Pine went to live on in spirit.

neilv 6y ago

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). 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. You can see the approximate day I regretfully moved away from Emacs VM email, due to this data conversion script: https://www.neilvandyke.org/bbdb2tbird/ https://www.neilvandyke.org/bbdb2tbird/

neilv 6y ago
When email providers were tacking garish ads onto emails from our friends, the easy extensibility of Emacs made it easy to add email ad blocking. :) https://www.neilvandyke.org/sigbegone/ https://www.neilvandyke.org/sigbegone/

preek 6y ago

Some people are discussing that receiving HTML emails Emacs doesn’t work well. Here’s a blog post and video showing that it does, indeed, work very well: https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_emails_even_with_html.html https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_e... Source: I wrote the article and have used Emacs for email many years.

cachestash 6y ago

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.

self_awareness 6y ago

> I cringe everytime I see an email written in rich text with broad lines going well over 150 characters. But you do understand that most of e-mail readers can do soft-wrapping, so you can choose when to soft break the line? 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.

preek 6y ago
I agree on what you said. Having said that, there’s no need to hard wrap using Emacs. Format flowed works just as well as in other MUAs.