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.
(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.)
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 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.
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:
user-full-name "My Name"
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?
(Edit: deleted, read the article first, dickhead)
(I don't like HTML email either, but that's a separate issue)
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?
I think. I'm not sure what you mean by dynamic link and have personally never needed to link to emails.
I also wonder hat "dynamic" means in dynamic link.
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 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.
> Just use Gmail
If you don't care about privacy and monopolies.
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.
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")
> 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.
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.
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.
"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."
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!"
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.
>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.
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.
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.
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.
Automating The Sims Character Animation Pipeline with MaxScript
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!
Interestingly other Lisp hackers were involved:
"Real-Time Garbage Collection in a Multimedia Programming Language"
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.
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.
It feels wrong to me to be maintaining so much unnecessary code in the core distribution.
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.
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 have a whole system built on top of it. See
EDIT: I've been using MH-E to read email since the 80's.
>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:
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.):
0U..H !* MAKE DISPLAY OCCUR?!
^[ B,.T FT^[..A^[ .,ZT' !* give printing lusers some hope!
^R ]..J !* LET USER TYPE HIS REPLY IN!
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^[
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.
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.
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.
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.
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.
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.
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 ' _place_holder;'"
I love being able to write my own Elisp code to have VM work exactly the way I want it.
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.
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 know, for some folks not already familiar with emacs that can sound crazy, but I've already invested in the learning curve.
But more recently, I'm pretty addicted to using the AI suggestions that GMail gives when composing an email.
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/
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 techies, which are something like 1-5% of the population. For everyone else, for grandpa and grandma, smartphones are a giant leap forward.
: Zawinski as in "jwz", Jamie Zawinksi: https://www.jwz.org/about.html
I'd advise linking to a archive.org version of the url.
(Mods, could you change it if you see this?!)
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.
I'm not aware of any serious bugbounty programs for Emacs.
Emacs exploits would be immensely valuable in the right contexts.
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.
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.
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 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've outlined areas of Emacs where exploitable vulnerabilities could lurk. But in my view, it's far from being a "bananas" situation.
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,
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?
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.