
Emacs as Email Client - yannikyeo
http://www.mycpu.org/read-email-in-emacs/
======
da39a3ee
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.

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

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

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

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

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

------
pbourke
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-s...](https://devrant.com/rants/520714/im-only-a-humble-customer-
service-representative-in-amazon-i-really-hate-the-ema)

~~~
PaulDavisThe1st
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
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#oi...](http://www.art.net/~hopkins/Don/lang/scriptx/tech-qa.html#oic)

>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...](https://medium.com/@donhopkins/automating-the-sims-character-
animation-pipeline-with-maxscript-bc490787d7a2)

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

~~~
DonHopkins
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++.

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

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

~~~
da39a3ee
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
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
It's well over a million lines of elisp, which is not small. But it's
certainly not much disk space.

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

------
e40
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
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/4e2ea8e4d851a0ea1f910c300...](https://github.com/PDP-10/its/blob/4e2ea8e4d851a0ea1f910c3001e5c2ddb9ff528c/src/emacs1/rmailx.1)

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
Makes INTERCAL look kind of bland and unimaginative.

------
preek
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...](https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_emails_even_with_html.html)

Source: I wrote the article and have used Emacs for email many years.

------
massysett
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
Receiving HTML mails work fine in Emacs, too:
[https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_e...](https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_emails_even_with_html.html)

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

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

------
bojo
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
Look up davmail. It proxies o365 to imap/smtp/caldav/carddav. I'm using it
with offlineimap.

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

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

~~~
girzel
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]

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

~~~
ylee
>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/...](https://lists.nongnu.org/archive/html/viewmail-
info/2020-05/msg00000.html)

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

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

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

~~~
Mediterraneo10
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
> 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
This is a forum by techies for techies. Was it really necessary to spell this
out?

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

~~~
mycpuorg
Wow! Source?

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

[https://www.jwz.org/hacks/#:~:text=Law%20of%20Software%20Env...](https://www.jwz.org/hacks/#:~:text=Law%20of%20Software%20Envelopment)

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

~~~
hornetblack
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
Uhhhhhhhhhhhhhhh, alrighty then........ can't edit or even delete now. Thanks
for the heads-up....

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

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

~~~
metroholografix
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...](https://www.cvedetails.com/vulnerability-
list/vendor_id-72/product_id-741/GNU-Emacs.html)

[2] [https://www.cvedetails.com/product/15031/Google-
Chrome.html?...](https://www.cvedetails.com/product/15031/Google-
Chrome.html?vendor_id=1224)

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

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

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

