Back to the origins: vanilla Emacs

After an intense but complicated love story with Doom Emacs started in 2021 I'm back to vanilla Emacs. Here are some thoughts after 4 years of Doom Emacs use.

Note: this article was written at the end of August 2024. After having used vanilla Emacs again for 4 months, I am publishing the final revision.

Reading again why I had switched to Doom Emacs at the time (it's great keeping a blog!), I had basically two reasons: hard to figure out Emacs configuration, refuse to learn Elisp. Things have changed a bit in the meantime and it's been a few weeks that I've been playing with the idea of giving vanilla Emacs another try at the first free time slot available.

The migration from Doom Emacs to vanilla Emacs took just a couple of days to get me a fully working environment, albeit unrefined. The fine tuning and configuration is a long tail of very low priority work with the goal of configuring the packages as much as possible as how Doom configure them out of the box. I am again in Emacs territory, where configuration never ends.

The previous paragraph is a sort of summary of my experience so far, but let's go into the details.

§ Comparing vanilla and Doom Emacs

§ 1. Out of the box experience

Doom: The richfulness of the distribution, easy out-of-the-box experience.

Emacs: you're given a scalp, a hammer and the Library of Alexandria. Now go and RTFM.

§ 2. The development model

In Doom development is opinionated and a bit chaotic. It has no stable releases, not even git tags. Breaking changes at every step (see here and here and here or this thread¹), "Arch Linux syndrome" (oh my God, I didn't update in 6 months, now what??). Doom Emacs has improved in these 3 years, an upgrade is not a nightmare anymore. Only starting from 2024 I could upgrade Doom Emacs without bulldozing and reinstalling it from scratch. I had to write my own guide and that is not exactly a good sign for a distribution that is geared at people trying to avoid complexity.

Emacs: in contrast it's slow and conservative but it will never break your configuration.

§ 3. Community support

I never joined the Doom Discord channel (very active, I hear): did I miss a lot of opportunities? ¯\(ツ)/¯ Other official support channels are different, though. The forum usually leaves a lot of questions unreplied, also basic questions, maybe from newcomers, so I wonder what would their first impression be. The Matrix channel, last time I checked, probably last year, was also all tumbleweeds.

On the other hand, I don't need to mention the staggering quantity of tutorial, support and sharing culture around vanilla Emacs that provides more tools, introspection and tips to learn or investigate issues. One other annoying thing about using Doom Emacs is issue triaging: first you have to figure out if the issue is in Doom or in plain vanilla Emacs. If the issue is on upstream package, the Doom maintainer will send you to upstream. Upstream maintainer will ask you first to remove all Doom layers to ensure the issue does not depend on Doom. I understand both sides, but it gets annoying fast.

§ 4. The documentation

Most important part of a project. Vanilla Emacs has an excellent, exhaustive and completely offline documentation, you will simply find everything. If I were stranded with my computer on an island without Internet² and a full Emacs installation, I could go from absolute zero to full mastery of Emacs and Elisp. That's an hyperbole but you get the point.

Emacs documentation has also bad parts. Emacs comes from another time and its documentation reflects that: it's overly verbose, lacks easy-to-use examples (just try M-x describe-function RET if), it's poorly interlinked. Sometimes I need to dig and understand few different bits before I figure out an actionable: how to get the complete picture is often unclear. As we all know Emacs is nothing but a huge Elisp code crunching machine and Elisp has its own quaint jargon and it's all so intertwined, it feels like being at a party of some university fraternity. Emacs documentation has that vague condescending tone that comes with a language that stubbornly refuses to replace archaic terms like yank and kill with copy and cut³. I mean, I started writing my own Elisp tutorial to interpret the official Emacs documentation and I feel quite stupid about that. To be clear, I like dense and dry documentation without emojis or "encouragements". Examples of what I consider good and not condescending documentation are the systemd man pages or the Postgres documentation.

Doom documentation is, in one word, poor. The main documentation you find as a user is on GitHub as markdown files generated from Orgmode files. The real documentation, the pages explaining the modules are somewhere else and in my opinion the two are not clearly linked. Once there, you're greeted with a slew of "TODOs" so you realize it's a dead end, basically unmaintained. Nowhere could I find an architecture overview of Doom Emacs.

§ 5. System footprint

Caching layers and terrible error logging make difficult to build a mental model of Doom Emacs and figure out where a problem is. Speaking of caching, disk usage (excluded system packages cache, which is the same for both) is big:

# my vanilla Emacs config and elisp cache
120.0 KiB	~/.config/emacs/
78.5 MiB	~/.cache/emacs/

# Doom Emacs config and elisp cache
160 KiB	~/.config/doom/
954.8 MiB -/.doom/

Doom Emacs aggressively optimizes startup time and runtime performances. Besides adding a layer of poor introspectability, it seems that sometime fails to deliver on this promise. To be honest, I never suffered from bad performances in my workflow caused by Doom Emacs, but I read around about users pulling their hairs because Doom performs very bad (like half a second delay on a keystroke press). I assume these edge cases are either configuration problems or Emacs chronic issues. But if users are desperate and can't figure out a solution, isn't this defeating the purpose of Doom ("Emacs but beginner-friendly")?

Vanilla Emacs (in my use cases) is slightly more responsive. I run Emacs also on a Raspberry Pi 4, every bit of performance I can squeeze is important.

§ 6. More context is needed

Configuring Doom Emacs requires you to be aware of a few additional gotchas (see this thread or this comment). Learning Doom macros is not a huge task per se, but translating install instructions commonly found in git repositories⁴ into Doom Emacs "lingo" is still a small additional mental step. Again, Doom Emacs should appeal to a userbase that doesn't want to be bothered with the Emacs complexities, and yet, users are being asked an additional bit of mental gymnastic.

§ What I learned in the meanwhile

Emacs is not that alien to me anymore, now it "clicked". I have more or less a mental model of how the basics work, I have developed an intuition about which part of the Emacs machinery could be responsible for something, so I can figure relevant keywords for searching a solution and I am more effective at leveraging its excellent tooling and documentation to (mostly) figure out stuff by myself.

Removed packages/features that I don't really need, therefore less potential for conflicts or backtracking to where something originates. Converged to using well-established and maintained packages.

While I am still not a fan of Elisp, I am no longer scared by it. With a bit of patience I can even write my small utilities to improve my work. It's a bit of a shame one has to learn a programming language and its library for just one application.

Emacs itself evolved. In 2021 I was using Emacs 27. Emacs 28 and 29 were released with a few important features (native compile, eglot, project.el, ...) that improved dramatically the user experience, making Doom Emacs less necessary. In Emacs 30 new external packages will be blessed and will be moved to the core installation, helping reducing further the search for a-package-to-do-this-thing.

§ Concerns about Doom Emacs usage in the long term

I keep reminding me that Doom Emacs is a gargantuan project in the hands of an overworked hero (with contributors) and I am happy to send him a few euros, but I read this as a point of weakness (bus factor = 1 and so on). There is not much official communication from the project to its userbase. Not a blog post, not on the official forum. Again: am I missing all the fun because I am not on Discord? If this is the case, then the Doom Emacs project should sooner or later deliver on its roadmap and open new channels.

Henrik Lissner, Doom Emacs maintainer, hints that the projects is suffering from its success. Which is a good thing to happen, but then it's also important to stop, breathe and spend some time sharpening the axe instead of trying to keep up with cutting wood.

§ Conclusions

No matter which flavor I use, Emacs is here to stay in my toolbelt. I have "backported" 90% of my Doom Emacs configuration to vanilla Emacs in about a week (because I didn't know which packages I was using in Doom). It took me a few weeks 😅 for the remaining 10% of fine tuning.

Also, I need to acknowledge the incredible work in terms of tutorial and learning material accomplished by the community at large. Emacs is a blank canvas where anyone can paint their own picture want, the amount of experimentation is infinite. This is overwhelming but also inspiring. In particular a big shout out to Protesilaos Stavrou, that was instrumental when choosing packages and understanding what they do. Please send him some money, if you can.