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.

Unimpressive Defaults

It’s hard to express just how bare-bones Emacs is without a desirable configuration. As an example, the dropdown completion menu that you’d expect from a modern editor requires a third-party package. That pattern repeats often and it means many details have to be tweaked by hand. To be fair, Neovim also relies on plugins like nvim-cmp for a polished completion experience, but its ecosystem has largely converged on a single well-supported solution rather than competing, partially overlapping ones.

Once you start adding packages, you’ll quickly find that there are several options for everything, each with their own trade-offs. What could’ve been a quick setup, can quickly turn into an hour-long research project.

It doesn’t stop there. Many of these packages ship with their own bare-bones defaults, requiring you to read long documentation pages just to achieve something that feels standard in other editors. When they conflict or don’t behave as you’d like, the fix usually involves sprinkling Lisp glue throughout your config. The popular distros smooth over much of this, but they do it by layering years of community patches and helper functions on top.

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 most about Emacs (e.g. Magit and org-mode) have near-identical replacements for Neovim.

For me, Emacs just wasn’t cutting it. I can’t say that Neovim will be the editor I use forever, but it’s the best one for me right now.