Emacs as Email Client | Hacker News Reader

Emacs as Email Client

mycpu.org

121 pointsyannikyeo105 comments

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.

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

> HTML email is useful for reviewing code, but you don't like when code reviews are done over email? Which is it?

I said HTML email is useful because it allows you to send syntax highlighted code to a friend. A chilled out, normal friend. I, err, wouldn't like to try getting Linus or emacs-core devs to review my patch sent as syntax-highlighted HTML.

Meh, Emacs can already syntax-highlight code, and it'll use the colors I've already chosen as the best for my taste. Your pre-highlighted html won't do that.

Yes. The normal way to do it is to send the whole file as an attachment.

That way, they can open it in their favorite editor with their favorite tabs setting and key bindings and... Favorite syntax highlighting theme -- who are you to force your own color scheme on others !?

They can also easily diff it against their own copy and maybe reformat it to their preferred indentation scheme.

> "Fewer Distractions"

I think the time between typing emacs on the command line to being "correctly" in the editor gets a disproportionate amount of developer attention.

(I have F2 mapped to "edit emacs startup file")

I'll add my two cents. I use emacs for email (mu4e+mbsync) and having used Thunderbird, Claws, Gmail, Roundcube (probably many others), emacs is, without a doubt (for me) the fastest way to launch/read/search/reply emails.

I can launch an emacs email client in 1/10th of a second, and it takes me straight to my inbox which is setup to highlight the emails I'm interested in. Opening an email to read is again 1/10th second (thanks to mbsync). Finally search via mu4e/xapian is blindingly fast (faster than gmail). For me, the competitors aren't even close.

Genuinely curious what your life is like such that an email app that takes longer than 1/10th of a second is just beyond the pale? Are you really that time poor?

It's really nice to have fast response clients. .1 or .3 seconds doesn't matter in the sense of saving 1000 seconds a day probably, but immediate response from tools is useful.

gmail is significantly slower: it's not like 1/10th of a second vs 3/10th of a second.

FWIW, the text under "Fewer Distractions" is about using mails in old-school pull mode, where it's you who decides when the e-mails will be fetched from the server, and most importantly, without any notifications. That's truly distraction reducing, and I've adopted the latter part (no attention-grabbing notifications) for myself too.

(Except the little Outlook popup on my work laptop, because I can't be bothered to make Outlook stop displaying it.)

> Just use Gmail and spend the time on something more worthwhile.

The point of all these "let's use Emacs for ..." articles is that, if you're already using Emacs, it won't take you that much more work to decrappify your life elsewhere. The UX we're inflicting on regular people is atrocious and extremely inefficient, and the reason people make Emacs into their personal OS is precisely to buy back time and sanity they'd regularly bleed out interacting with the computing world "the right way".

Like, sure, I'd use GitHub PRs because they're more obvious to someone not used to patchsets, but does anyone regularly works on their code using GitHub's built-in in-browser editor? No, it's much, much more efficient and ergonomic to limit interactions with GitHub to `git fetch`, `git pull` and `git push`, and do everything locally with your text editor/IDE, and local repo management. The same applies to other tasks used regularly - a powerful, ergonomic interface beats the toy interfaces developed for casual users.

(I mentioned Outlook before. I hate its occasionally unpredictable IMAP behavior, frequent failures on fetching mail or calendar data (unless you're connected to MS Exchange system, then it works like a charm), and various other quirks. I still like it more than GMail's web interface, or really, any other web interface to e-mail.)

> if you're already using Emacs, it won't take you that much more work to decrappify your life elsewhere.

But, alas, it often does take more work, and often a lot more. It's gotten better lately with things like (use-package...) but the old yarn about a user's .emacs file being like a lightsaber that you have to make yourself, no one else can use it, takes a long time, and requires constant attentions and many failures to get even close to usable is no less true now than it has been since its inception. Email is HTML now, emacs isn't great at it. Use the right tool.

I went down the rabbit hole mostly as an ideological thing. Everything I do with a computer that isn't video or shopping (so anything that has anything to do with being productive) is centered around the idea of navigating, reading and/or manipulating text.

Most tools today seem to try their best to destroy that experience. Emacs does not. My main gripe is that Emacs isn't enough of an operating system. I don't like having to leave. The thought of an expanded Emacs with a unified GUI centered around text is for me almost a wet dream.

I have been running EXWM (emacs window manager) on top of GNU Guix for a few weeks now, and while it’s not perfect, it’s the closest I’ve come yet. I also use eshell as my default shell, so except for when running icecat (Firefox), next (Common Lisp based webbrowser), mpv for the odd video, or alacrity when eshell is not enough, everything is just emacs buffers and it’s actually great.

I have almost the same setup, except use the vterm emacs package as my backup shell instead of alacrity - while vterm doesn't integrate with emacs as well as eshell (no redirecting into buffers/calling elisp functions), I prefer it to an external shell, as I can keep my emacs bindings in the shell and share the kill ring.

Thank you for mentioning vterm! It is just what I have been looking for!

> You will waste a LOT of time getting it set up and fiddling with it.

I'm always a bit surprised by people claiming Gnus is hard to configure. When I decided to try Gnus, I opened the manual and it says which variables to set:

    (setq 
     user-full-name "My Name"
     user-mail-address "my.email@address"
     send-mail-function 'smtpmail-send-it
     smtpmail-smtp-server "smtp.gmail.com"
     smtpmail-stream-type 'starttls
     smtpmail-smtp-service 587
     gnus-select-method
     '(nnimap "gmail"
              (nnimap-address "imap.gmail.com")
              (nnimap-server-port 993)
              (nnimap-stream ssl)
              (nnmail-expiry-wait immediate)))

Must have taken less than 10 minutes to setup. Haven't touched that configuration since then.

Now, many people complain about the difficulty of setting Gnus up, so it must be true. My best guess is that what is actually hard to setup is external mail fetching and indexing. I've never tried that. Were offlineimap and dovecot hard to setup?

I don't paticularly feel the need for external fetching and indexing: Gnus is already much, much faster than loading the Gmail webapp, and is comparable in speed to using the web app's reload button (not the browser reload button).

Now, many people also complain that fetching mail with Gnus is slow, so it must be true. My best guess here is that either they are comparing to something much faster than Gmail or they have a very different email usage pattern than I do. Maybe they keep a lot of email in their inbox?

I'm an emacser, but I have never touched gnus purely because I have no idea how to make a dynamic link towards an email in my org projects file.

With gmail, I simply copy the URL and mark it up under my project headline in the org file.

How do you do that with gnus?

When you are looking at the email in gnus C-c l (org-store-link) then in the org file C-c M-l (org-insert-last-stored-link)

I think. I'm not sure what you mean by dynamic link and have personally never needed to link to emails.

Minor point: org-store-link comes with no keybinding, C-c l is something you chose in your config (I use C-c s).

I also wonder hat "dynamic" means in dynamic link.

This is not the first time someone has corrected me about default emacs keybindings. Considering that I probably set up that keybinding 15 years ago, it sure feels to me like it's part of emacs. I guess the next time I am trying to give some advice I need to do some software archeology on my .emacs first.

Maybe it's better now. Many years ago I sat down to properly make a move from whatever email client I had, to gnus. I wasted a lot of time. While I got it working pretty fast it glitched repeatedly. I just wanted a working email client in emacs, I couldn't get that, I gave up.

(Edit: deleted, read the article first, dickhead)

(I don't like HTML email either, but that's a separate issue)

> The die-hards who still, in 2020, complain about HTML email are just wrong and absurd.

I understand not liking HTML email, but I agree that complaining about it is unnecessary. For one thing, in my experience practically no message of any importance whatsoever is in HTML. I could simply not read any HTML email and no-one would ever notice.

Of course, this is isn't true for everyone: while I have no first hand experience of this, there are apparently some work environments were people receive HTML email that actually is important for them to read. If the formatting isn't too complex, say, just a few headings, italic text and images, then rendering it in Emacs with shr works just fine. For more complex HTML that Emacs can't handle, Gnus has K H, which opens it right away in a browser window.

Now, if you feel pressure to send HTML email, not just to read it, then you can use one of several Emacs packages to write in Org mode or Markdown and have it automatically converted to HTML and sent as email. I actually do this sometimes for math-heavy emails and it works just fine (my previous system for that was to send people PDFs).

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

OK, that I disagree with but just because color schemes are highly personal. It's more comfortable to read that code in your own text editor, with your preferred color scheme. Doing so is easier if you were reading the email inside your text editor to begin with.

> Gnus has K H, which opens it right away in a browser window.

When doing this mind that HTML engines in many mail clients are limited. However when using the default browser the mail can run JavaScript and can remote load images, which allows tracking when you read the message.

Oh, good point! Good thing I never need to read HTML email, then.

Unrelated to the topic, but:

> Just use Gmail

If you don't care about privacy and monopolies.

Then just use Fastmail or similar, but that's not his point.

or speed of the interface for that matter

> The die-hards who still, in 2020, complain about HTML email are just wrong and absurd.

Change that to people who complain about email not being only plain text, and I'd agree. In hindsight it should have been obvious from the moment it got named "email" instead of "etelegram" that people were going to want rich formatting--if they could print it on paper and send it in the physical mail they would want to be able to skip the paper and send it via email.

It's not obvious, though, that HTML was the best format to use for rich email formatting so I think there is room for someone to complain about it without automatically being wrong and absurd.

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

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

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.

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/ScriptX

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/

    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/

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

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

I only said it was like C with classes.

I don't remember where the decision came from, really. I had been working in C++ quite a bit at UWashington CS&E before starting Amazon (mostly on some private artificial life code), after about 5 years of working in C. It was such an obvious step forward, I didn't want to be limited to C only. As I recall, Shel was nervous about using too much of C++, which he was less enthusiastic about but also willing to see the upside of a limited subset of the language.

Having been an onlooker in glib's "Objects in C" attempts for the last 20 years, I remain extremely happy to work in C++. I've just been implementing a constraint layout engine in C++ (using Kiwi) and comparing my code with what has to be done in the GTK version (written in C using glib's object model), it's hard to even begin to make a comparison. Let the compiler do it!

I got a kick out of how Dave Ungar implemented the original Self compiler with a whole lot of hard core C++ code. Implementing such an extremely un-C++-like language as Self in such an extremely un-self-like language as C++.

I guess once you cross the Greenspun's tenth rule threshold, everything is possible :).

It has never been released?

Interestingly other Lisp hackers were involved:

"Real-Time Garbage Collection in a Multimedia Programming Language"

https://pdfs.semanticscholar.org/7fa1/6e4c4c92d45e4435646bac...

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.

same. i was a huge Gnus user. the combination of email and usenet was nice. a bygone era.

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.

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.

It's well over a million lines of elisp, which is not small. But it's certainly not much disk space.

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.

I've used Emacs/GNUS for just shy of your two decades myself. It was Emacs/VM before that.

Note, you can incorporate notmuch into GNUS. From the groups buffer I type G G and type some search terms into the minibuffer and get a notmuch buffer of results. I can browse them and if I find one I want I can do C-c C-c to return to the GNUS buffer with threaded context of that message.

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

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.

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

EDIT: I've been using MH-E to read email since the 80's.

Or RMAIL or 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/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

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

Makes INTERCAL look kind of bland and unimaginative.

I also used MH-E in the 80s. Around the turn of the century I switched to 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.

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

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.

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.

Receiving HTML mails work fine in Emacs, too: https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_e...

Anyone remember Pine? Now, that was an email client. [1]

[1] https://en.wikipedia.org/wiki/Pine_%28email_client%29

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

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.

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.

Yes. I really miss it, but I'm just not sure how practical it is anymore.

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.

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.

True. I think the workflow will continue to be fragmented even with richer email content.

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.

Emacs does have its own renderer, eww, that can be used to do simple HTML rendering of emails. If I'm sent something really gruesome, "K H" will send it to Firefox to display.

In my experience, the mails that refuse to display anything but "please view this message in your browser" are never mails I actually want to look at.

I'm not arguing that you have to be willing to put up with some friction! But to me it's not that bad.

[edit: typo]

I do the same, with VM; 25 years and counting. My Emacs doesn't have EWW but W3M is sufficient for almost all HTML messages; for me shift-H is the keybinding that sends a message to the browser should I want to view it that way.

I love being able to write my own Elisp code to have VM work exactly the way I want it.

I use mu4e and a lot of what the author says is spot on. Searching email with mu is super fantastic for example.

Viewing html email in emacs is usually pretty easy. The html2text is usually good enough.

The real problem is sending email. Plain text email looks like trash in any modern mail reader. Any recipient will wonder why your email is broken. On a desktop client the lines will be way too short. On a phone, too long.

Format flowed or whatever doesn't solve it. The lines just need to be html paragraphs.

I saw a blog post about an mu4e plugin that would allow you to write your email in markdown, and it will htmlify it for you. That would be a big help, assuming you can preview before sending. It is easy to make markdown errors without a preview.

>The real problem is sending email. Plain text email looks like trash in any modern mail reader. Any recipient will wonder why your email is broken. On a desktop client the lines will be way too short. On a phone, too long.

I disagree on "too short" lines being a problem for desktop, but in any case, it is quite possible to send plaintext mail without 70-column line breaks. How I do so in VM in Emacs: https://lists.nongnu.org/archive/html/viewmail-info/2020-05/...

I've had to stop 25 years of muscle memory of M-q while writing a message, but otherwise the solution seems quite satisfactory.

> I saw a blog post about an mu4e plugin that would allow you to write your email in markdown, and it will htmlify it for you.

Perhaps this?

https://www.reddit.com/r/emacs/comments/g6ujzs/sending_richt...

Would be wonderful if this was incorporated into mu4e.

As for html2text, there's also the Python-based html2markdown, which I prefer.

mu4e-html2text-command "html2markdown | grep -v '&nbsp_place_holder;'"

I think we need to be clear, there's two issues here.

1. Receiving html emails in emacs

2. Sending plain-text emails in emacs

I personally do not find 1. to be a problem at all. If the html gets garbled in my automatic html2text conversion (I use html2markdown) then opening it up in Firefox is just a keypress away. Easy.

I agree that 2. is an issue, however in the rare occasions that I do need to write an html email, I just open up Outlook or Gmail or whatever. We don't have to be Richard Stallman about this. You can use another client when you need to. For me, 99% of the time emacs/mu4e is absolutely adequate, and better than the Outlooks/Gmails for a host of reasons. Let's not throw the baby out with the bathwater.

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?

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

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

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/

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/

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.

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.

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

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

This is a forum by techies for techies. Was it really necessary to spell this out?

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

Wow! Source?

https://en.wikipedia.org/wiki/Jamie_Zawinski

This is known as Zawinski's Law[1]:

https://www.jwz.org/hacks/#:~:text=Law%20of%20Software%20Env...

[1]: Zawinski as in "jwz", Jamie Zawinksi: https://www.jwz.org/about.html

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.

Uhhhhhhhhhhhhhhh, alrighty then........ can't edit or even delete now. Thanks for the heads-up....

(Mods, could you change it if you see this?!)

I am pretty sure Emacs could already read and send email by the time JWZ formulated this law...

Jwz knew that, because he worked on Lucid Emacs.

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.

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.

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.

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.

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.

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.

Five minutes might tell you there is no (eval) in the path but I don't see how thats useful.

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?

I wouldn't run any irc client without firejail these days...

I think Emacs should change enough that thats more viable then it is today.

Really you are only poking at one set of vulnerabilities anyway?

Why argue for more complacency? There is plenty of that, it never needs a champion.

I'm not arguing against firejail, just trying to understand your threat model. Security exists on a spectrum and there are multiple trade-offs one has to think about. Do you run Python scripts that interact with the network in firejail?

I've outlined areas of Emacs where exploitable vulnerabilities could lurk. But in my view, it's far from being a "bananas" situation.

IRC has decades of vulnerabilities and unexpected behavior atop its simple protocol.

Sitting on irc with 100 channels full of randos,

Emacs modules that aren't irc but also process text coming through for X or Y,

misconfiguration,

mime link handling,

irc protocol handling,

sloppy bot making "hey the builtin pretty printing for python code snippet had more implications then I anticipated",

"stuff" running in emacs in between network and the irc client,

add that to "noone seems to talk about or care about security issues in Emacs",

yeah a big pile of risk that pretty tough to just write off, for me, to that point I think it's bananas.

Especially when compared to the trivial alternative of sandboxing another client that has much less surface then a fully configured single process Emacs.

You are doing what you are doing and on some level we aren't too far apart in viewing the safety of a sandboxed raw emacs+some tight set of irc+a convenient plugin X and Y vs another irc client sandboxed. But I bet you aren't doing that.

I really dislike the words "threat model" in security conversations like this.

Neither of us has actually done any of that formal process for this, so why ask for it?

Why do you dislike "threat model", it's a necessity. There can be no productive security discussion without a model present to frame and ground it in actuality. Given a determined, resourceful adversary, you're toast regardless of what you do to protect yourself.

It makes sense therefore to have a realistic model and prepare accordingly. The probability that "100 channels full of randos" are going to use any of the -aspecific, hand-wavy- vectors you mentioned to defeat my security posture (which includes an IRC client written in a memory-safe language whose code I've reviewed that is masquerading through CTCP version as something else entirely) is miniscule. I can live with that but I've also spent some time to configure Emacs according to guidelines I previously mentioned and review code that I'm using and exposing to potential attacks.

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

[2] https://www.cvedetails.com/product/15031/Google-Chrome.html?...

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.

Chrome probably has 1 (2?) billion users. Emacs has what? 100k at best? The financial incentive to attack Chrome is much, much higher.

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

Sounds like you will :)

You can take a look on http://emacs.zeef.com/ It's a good starting point for your rabbit hole into Emacs.

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.

Reply on news.ycombinator.com