I Really Tried to Like Emacs

Sometime in late 2024, I switched from Neovim to Emacs. I was inspired to give it a try after learning that many of the developers at Jane Street use Spacemacs.

The choice is not obvious for someone who is just learning about these editors. In this post I want to reflect on why I ultimately decided to switch back to Neovim after spending a lot of time in Spacemacs, Doom Emacs, and eventually trying to perfect my own Emacs config.

Vim Converts Will Fight Evil

When I first found out that Emacs had a package to emulate Vim keybindings (evil), I thought it would be a silver bullet. Being able to leverage my existing muscle memory did make the transition much easier.

But every third-party package runs the risk of adding keybindings that don’t have a direct translation.

A concrete example of this can be found in the Dirvish¹ package. In order to create a file, the only option is C-x C-f. Of course I could remap that to something more aligned with the Vim philosophy like SPC cf, but having to do this for every offending package is a chore and requires you to spend a lot of time considering the ergonomics of those keybinds and potential conflicts with the existing ones.

There were countless times where I considered dropping evil altogether and switching to the stock Emacs keybindings, but I always found that evil has better ergonomics and is much more powerful.

Nothing Can Replace Oil

I still remember when I first tried oil.nvim. It was so different that it took me a minute to understand but so simple that it took me a minute to master.

There’s a lot of opinions when it comes to file management. Some people prefer having a sidebar like in VSCode, others prefer to save that screen space and opt for something more… on-demand.

Emacs has plenty of options for file managers (treemacs, neotree, dired, dirvish, ranger, etc.) I’ve used them all and in my opinion, none are as ergonomic or as beautiful as oil.nvim.

Single-Threaded for Life

This is a tough pill to swallow in 2026, but Emacs is “effectively” single-threaded and will likely stay that way. In practice, that means any long-running process is going to block the editor.

Imagine using Emacs as an IRC client and someone sends an image with inline previews enabled. On a slow connection, while that image downloads and renders, the whole editor stalls. No input. No redraw. Just a frozen UI until the work completes.

Maybe you don’t intend to use IRC, but I guarantee nearly every Emacs user has experienced this on more than one occasion.

Poor LSP Support

The first-class LSP client “Eglot” was made available to Emacs in 2023… 47 years after the release of Emacs. I think it’s safe to say that Emacs was not built with LSPs in mind.

There’s a popular third-party package called lsp-mode². And while lsp-mode is pretty good, getting it properly setup with each language was never as simple as I had hoped. I remember spending multiple days getting it to play nicely with my React/TSX projects. Even still, it occasionally requires a full lsp-workspace-restart to recognize a change I made and there’s no easy way to toggle comments in TSX…

I’ve never tried using Eglot because it’s less feature complete and I wasn’t interested in spending another few days getting it to work with the languages I use.

While writing this post, I opened a TypeScript file just to see and it froze my editor for around a second while it loaded the LSP server. This happened so often that it just became normal. Now that I’m back to using Neovim, I’m shocked I tolerated this for so long.

Startup Times

Vanilla Emacs opens in under a second. As you add packages, the time it takes to start will continue to grow. My fully-configured setup takes about 2.17 seconds to start on my machine. That is still faster than VSCode, but it can’t compete with Neovim. My fully-configured Neovim setup takes less than 200ms to start.

The startup times are so bad that many people opt to run an Emacs daemon and use the “Emacs (Client)” to spawn a connection to the already running daemon. This significantly speeds up the time it takes to open Emacs, but it is not a silver bullet and using the daemon can cause weirdness in certain packages.

You’ll Need Some Lisp

Unless you delegate configuration to an LLM, you’ll need to learn some Lisp (the Emacs kind) to truly get the most out of Emacs. I’ve been reading and writing code for quite a while and I’ve never seen Lisp used outside of academia or Emacs.

It could be argued that this is no different than Neovim requiring you to learn Lua, but I think Lua is simpler, easier to read, is widely used and requires much less “programming”, you can get away with copy-and-pasting snippets into a fully-featured Neovim config.

In Summary

I really did try to like Emacs; while I didn’t highlight what Emacs can do well in this post, there were moments when I thought it would be the editor I use forever. But every so-often, something would come up and cost me a few hours or days to get right. I don’t want to spend half of my time configuring my editor, I want things to just work and I want them to be fast.

To me it feels like Emacs is stuck in the past. Distros like Spacemacs and Doom Emacs do great things to modernize the experience, but it is very much putting lipstick on a pig. These distros have to do so much heavy lifting to make the experience good that it begs the question:

“Is Emacs even that good?”

When I came back to Neovim, I had a new perspective of what I wanted in a code editor. To my surprise, some of the features I loved about Emacs (e.g. Magit and org-mode) have near-identical replacements for Neovim. It is seemingly less common to see Neovim plugins ported to Emacs packages. For me, Neovim is the obvious choice. I can’t say it’ll be the editor I use forever, but it’s the best one for me right now.