I used Doom Emacs for over a year. Evil keybindings, SPC-leader menus, batteries-included config for every language I touched. It was fast, opinionated, and gorgeous out of the box.
Then one day I ran doom sync and half my config broke. Again. And instead of debugging it, I thought: what if I just… didn’t?
What Doom actually does for you
If you’ve never used Doom, here’s the pitch. Emacs by itself is a blank canvas — powerful, but aggressively unhelpful. No syntax highlighting theme. No file tree. No fuzzy finder. No sane keybindings unless you’ve been using Emacs since the Reagan administration.
Doom fixes all of that. It’s a framework that sits on top of Emacs and gives you:
- Evil mode — Vim keybindings, so you’re not contorting your pinky on Ctrl-x Ctrl-s all day
- SPC leader key — press Space, get a organized menu of every command you’d ever want
- Modules — toggle on
python,org,magit,treemacsin a config file, and Doom installs, configures, and wires them all together doom sync— one command to install packages, compile Elisp, and regenerate your environment
It’s genuinely impressive. For someone new to Emacs, Doom is the difference between “I gave up after 20 minutes” and “I’m productive on day two.”
So why leave?
The accumulating friction
Three things had been building up.
The sync cycle. Doom has its own package manager, its own compilation pipeline, its own env file that snapshots your shell variables. When it works, doom sync is magic. When it doesn’t, you’re debugging a build system for your text editor. I’d change one line in packages.el, run sync, and get cryptic Elisp stack traces about autoloads. The fix was usually “nuke .emacs.d and re-clone Doom,” which takes ten minutes and feels like reinstalling Windows to fix a printer.
The abstraction layer. Doom’s module system is a DSL on top of Elisp, which is already a DSL for configuring Emacs. Want to customize how magit opens buffers? In vanilla Emacs, you set magit-display-buffer-function. In Doom, you set it in the right section of your config.el, but also Doom has its own opinion about magit’s display, and your setting might get overridden by the module’s +config.el, and you need to check doom doctor to see if your config is even being loaded in the right order.
Every Doom debugging session eventually becomes: is this an Emacs thing, or a Doom thing? And figuring out which one is half the battle.
The update anxiety. Doom is a moving target. It tracks Emacs HEAD and its own development branch simultaneously. doom upgrade pulls changes to the framework itself, and those changes can interact with your config in surprising ways. I found myself avoiding upgrades because I didn’t want to spend an afternoon un-breaking things. That’s the opposite of what a tool should feel like.
The moment
May 2025. I ran doom sync after enabling a new module. Got an error about evil-window-map being void. Searched the Doom Discord. Found a thread from three months ago with no resolution. Tried the usual rm -rf ~/.emacs.d && doom install dance.
And then I just… stopped. Opened a terminal. Ran brew install emacs-plus@29 --with-native-comp --with-modern-icon. Created ~/.config/emacs/init.el. Wrote 15 lines of config.
It was the quietest my editor had been in a year.
What vanilla Emacs feels like
The first thing you notice is silence. No splash screen with ASCII art. No “Doom loaded 247 packages in 1.2s” message. Just a blank buffer and a cursor.
The second thing you notice is that nothing works. No SPC menu. No evil mode. No theme. C-x C-f to open a file, like it’s 1985.
And then — this is the part that surprised me — you start adding things back one by one, and each one makes sense in a way it didn’t before.
(use-package magit
:bind ("C-x g" . magit-status))
That’s it. That’s all the magit config you need to get started. No module, no +config.el, no wondering if Doom is overriding your settings. You install the package, you bind a key, it works.
I rebuilt my entire editing environment in an afternoon. Not because vanilla Emacs is faster to configure than Doom — it isn’t, the first time. But because every line in my config does exactly one thing, and I know what it is.
What you lose
I’d be lying if I said there was no cost.
Evil mode requires manual setup. In Doom, Vim keybindings are woven into everything — magit, org-mode, dired, the minibuffer. In vanilla, you install evil and evil-collection, and most things work, but there are gaps. Some buffers don’t respect evil bindings until you configure them explicitly.
The SPC leader ecosystem. Doom’s SPC menu is genuinely great for discoverability. You press Space and get a categorized list of everything: files, buffers, windows, git, search. In vanilla, you build this yourself with general.el or which-key, and it’s never quite as polished.
Sensible defaults. Doom makes hundreds of small choices — line numbers in programming modes, UTF-8 everywhere, reasonable undo behavior, smooth scrolling. In vanilla, each of those is a setq you have to know about and write.
Community packages. Doom has packages like doom-themes, doom-modeline, solaire-mode that are designed to work together as a visual system. You can use them without Doom, but some of the cohesion is lost.
If you’re someone who wants a great editor and doesn’t care what’s under the hood — Doom is probably still the right choice. It’s not bad software. It’s good software that I outgrew.
What you gain
Understanding. This is the big one. After a year of Doom, I could use Emacs, but I didn’t understand Emacs. I didn’t know what use-package does because Doom has its own use-package! wrapper. I didn’t know about eval-after-load because Doom handles load ordering for you. I didn’t know that package-archives is just a list of URLs because Doom has its own package pinning system.
Vanilla Emacs forced me to learn Elisp — not deeply, but enough. Enough to read a package’s source and understand what it’s doing. Enough to debug my own config without searching a Discord.
Stability. My vanilla config hasn’t broken once since May. There’s nothing to sync. No framework updates to track. Package updates come through package-refresh-contents and they’re self-contained — if one breaks, it doesn’t cascade.
Speed. Not startup speed — Doom is actually faster there because of aggressive compilation. I mean the speed of making changes. I edit init.el, eval the buffer, and the change is live. No sync step. No compilation step. No “did Doom’s module override what I just wrote” step.
Ownership. Every line in my config is mine. I wrote it, I understand it, I can change it. There’s no hidden layer between my intent and Emacs’s behavior.
The practical move
The actual migration took about an hour. Not because vanilla Emacs is simple, but because I’d already done the hard part — I knew what I wanted my editor to do. Doom taught me that.
The steps aren’t complicated. Remove Doom’s directories (it scatters across ~/.config/emacs, ~/.doom.d, ~/.emacs.d). Install emacs-plus via Homebrew for native compilation. Create a fresh init.el with use-package. Add packages back as you miss them.
I have a separate post that covers the how-to if you want the specifics.
The part nobody tells you: you won’t miss as much as you think. The 80% of Doom you actually use is maybe 30 packages and 50 lines of config. The other 20% was framework overhead you were paying for but never using.
Who should stay, who should go
Stay with Doom if:
- You’re new to Emacs and want to be productive quickly
- You don’t want to think about config — you just want it to work
- You love the Evil + SPC workflow and don’t want to rebuild it manually
Consider vanilla if:
- You’ve been using Doom for 6+ months and keep hitting the same walls
- You want to understand what your editor is actually doing
doom syncgives you anxiety- You’re the kind of person who reads the source code of the tools you use
There’s no wrong answer. Doom is a great on-ramp. Vanilla is where you end up when the on-ramp starts feeling like a toll road.