A whole bunch of people that I consider very smart and accomplished kept recommending Emacs to me as a text editor. This goes back to at least 1996, so it has nothing to do with the current Emacs renaissance. But while I found the editor more charming than quirky, I bounced off of it every time I tried it.

Fast forward to February, 2026 and I’m fed up and frustrated enough by text editors in general that I’m ready to try again, for real this time. This was the start of my configuration file pregnancy. Now that the baby is more or less born and has all its limbs, I want to look back at some of the reasons I had for sticking it out with Emacs.

But first, the frustrations.

Why not VS Code? #

VS Code is the 362 kilogram gorilla and it absorbs anything in its immediate vicinity. It thrives on its extension system, which does seem to be pretty adequate, but the quality of extensions varies wildly and its popularity means you’re hunting for that one good extension for your use case more than you’re actually using the editor.

Let’s not even start about the parts that are entirely proprietary, like the remote editing components, Pylance, etc. The free(er) builds like VS Codium and Code OSS (the Arch package) aren’t always a good solution because they’re restricted to non-Microsoft extension marketplaces. Not everyone publishes there.

Those projects, as much as I respect them, will also never escape the fact that it’s Microsoft who makes all the calls in this project. There is no real collaborative governance. If you wanted that, you’d need to hard fork, and I don’t think anyone wants to take on that burden.

Even if we disregard the obvious problems, the last ten, fifteen release notes for VS Code were mostly about improving LLM agent management features and agentic coding. Very few people at Microsoft seem to be focused on what humans, not machines, want to do with a text editor.

Why not Sublime Text? #

I would be willing to use something even more proprietary than VS Code if it means a fantastic experience. Back in 2010 or so when I last used Sublime, it was just that.

Nowadays it’s still a very fast, quite capable editor and I was surprised that even LSP support is very OK despite being a plugin and not core.

But Sublime’s future looks uncertain to me, I read reports of people getting frustrated with the slow pace of development, the new plugin API not being adopted by everyone and a bunch of plugins being left without maintainers. Also, it changed licensing at some point to a yearly subscription instead of a one-off payment. I’m not sure how sustainable this will be.

I can’t say I hit any big snags while I tried it. The Git UI (Sublime Merge) that’s available separately seemed really nice and it’s something I could recommend to colleagues afraid of the command line. But ultimately it was a gut feeling more than real frustration that made me skip this one.

Why not Kate? #

Kate is another very fast editor written in C++ and it seems to do 90% of what Sublime does. But the plugin system requires plugins to be written in C++ (yes, I know you can add scripts as external tools but that’s not the same thing).

The core features that are there work very well, including LSP support. It only supports one language server at a time but you can get around that problem by multiplexing using an LSP multiplexer like Rassumfrassum.

Kate is part of the KDE project which means its improvements go upstream to other KDE components and their improvements trickle down. For example, syntax highlighting and the general text editor controls only have to be invented once to benefit all KDE subprojects. This is a neat trick, the only downside is that when other text editors seem to be converging either on Tree-Sitter or TextMate grammar bundles, maintaining your own set of basic language support plumbing might be dangerous.

On the other hand, monocultures bear their own dangers so please, KDE team, Christoph Cullman and all involved, continue on this path.

If all other editors disappeared and I had to use only Kate, I could get along with it.

Why not Zed Editor? #

The obvious part is that it’s a VC-driven project and that Zed Industries seems to be pivoting (excuse the corporate bullshit term) to LLM-wrangling now. I see Zed falling behind. No, this is not just about which side of the window the project explorer/file list is on by default; Zed have LLM-pilled themselves even more heavily than Microsoft.

Zed also shares the Kate problem of having a plugin system in a compiled language (Rust in this case). Thanks to lewrker for pointing this out to me, but systems like these are nonsense, you want some interpreted language for this problem. We’ll get to that later with Emacs.

Why not Gram? #

Gram is an extremely interesting hard fork of Zed that was created out of anger; the best kind of motivation for some people.

I’ve been using Gram off and on since it came out and even have a small pull request that got merged into the project. I was curious about Rust in a big codebase such as a text editor, just like Gram’s original author, krig. But I’m not sure my Rust-fu will ever be good enough to contribute regularly.

I was a bit shocked to find out how chaotic Zed’s code base really is. This might be the heavy use of LLMs showing, but there is repeated code for no reason, there are four different async implementations in use at the same time and the general ergonomics are not great. This isn’t just my Rust-newbieness talking, there are some experienced Rust devs in the project and even they are frustrated sometimes.

But the good news is that the project is well aware of all of Zed’s shortcomings and is slowly addressing them. There are talks of a more flexible plugin system, for example.

This is one to watch.

Why not NeoVim? #

Talking about flexible, interpreted plugin languages, NeoVim chose to support Lua in addition to Vimscript and that surely helped turbocharge its adoption.

I’ve been maintaining a half-decent NeoVim configuration for a few years now, and I was OK with having to redo whole chunks of it on every upgrade. I’m reasonably competent with vim motions and keybinds, I’m still faster to this day in vim than in Emacs. But I never fully got to grips with the mnemonics for some more advanced commands.

LSP functionality especially often descended into a swamp of keybindings I had to write out on a piece of paper since NeoVim lacks the advanced online help/documentation that Emacs has, so the frustrations kept growing.

Add to this things like the nvim-treesitter debacle or justinmk, NeoVim’s main person, seemingly seeing nothing wrong with keeping a DHH endorsement on the project’s main page, these are some smells that add up for me.

I know that the former problem seems to be solved now, you can use Arborist or go to the newly revived nvim-treesitter thing, but these are not problems I want to have when I use a text editor. Basic stuff like syntax highlighting, even if it’s a difficult problem in some languages, should just work and should be core or close to core, not some external project.

Emacs supports both Tree-Sitter and its own highlighting engine with various levels of support, but all from its core, so it’s in a better shape than NeoVim.

Why not vim? #

Last I tried, it took several external projects to get basic LSP support working. And some of the things I want, such as a theme I can stare at all day, seem to exist only for NeoVim, not vim.

I’m honoring Bram’s legacy by still having vim on every server and I use it for quick config file edits. But I don’t think I’ll ever start using it for big projects and programming.

Why not Flow Control? #

This Flow Control is what I mean, it’s a young editor so I feel I have to link to it.

I skipped it simply because it didn’t support region indent and autoformatting when I tried it, or some other very basic thing was missing, I can’t remember exactly.

It’s an impressive project, though, and one worth watching. Basically a mixture of Sublime Text and vim for the console, but with none of the baggage. I can see myself replacing vim on my servers when this matures. And unlike vim, I could see myself using this even for “real” programming.

Why not IntelliJ IDEA? #

Actually, the question is not as dumb as it might seem. And while 5.5 GB RAM is excessive for editing a single Python file, the JetBrains products are quite polished and most of the languages I use work reasonably well in them.

The biggest difficulty I had was with the keybinds; my reasoning is that if I have to rebind almost every key to get more or less what I want from IDEA, I probably profit more from investing the same amount of time in an Emacs config but getting exactly what I want instead.

Also, the Java lineage is very obvious, with dozens or hundreds of plugins geared towards that mega-gigantic ecosystem. Just browsing the list of preinstalls made me feel like some sort of J2EE developer from the early noughties, grasping at every straw of editor support to keep from going completely insane while implementing the sixteenth AbstractBufferedJavaBeanFactoryVisitorPatternGenerator of the day.

It’s not a world I want to visit, but I think I could get along with it if I had to.

Why not Lite XL, Lapce, CudaText, Kakoune, Geany, CotEditor, Pulsar? #

I did give some of these a shot, but I’m only interested in cross-platform editors because I’m forced to use other platforms than Linux for work. That leaves only a few that are interesting, but they turned out to be either too quirky or in a state of semi-abandonment.

Not to disparage those projects, they each have their place, but I had too much friction trying to set them up for my most frequent use cases.

Back to Emacs #

So why Emacs?

The previous paragraphs probably made it very clear that writing a decent text editor is difficult. Making it extensible and human-friendly even more so.

Every product on the list takes some shortcuts and accepts some tradeoffs. You won’t find the perfect text editor, unless you write it yourself. So you have to aim for the one where the tradeoffs meet your needs the best, and then work around any niggles that remain.

That is where Emacs performs the best for me. How it does that:

• The plugin system uses a powerful language and allows very deep customization of almost every part of the editor. Far more so than most (or all) other editors.

  • The language can be byte-compiled to speed things up, so being interpreted is less of an issue now than it was a decade or two ago.

• There are people in the community who care very deeply about ergonomics and quality; Protesilaos with his themes, minad with the Corfu + Consult + Vertico triple-punch, Joao with very strong opinions on LSP support and the code to back them up, the dozens or hundreds of authors who maintain their own little package that scratches their own itch and might also scratch yours.

• On average, the quality of Emacs packages is way ahead of what you find in most editors, the largest difference I saw is between Emacs and VS Code. Where the Code marketplace will vomit out any old garbage and has sixteen plugins that solve the same problem, each of them in a half-broken way, Emacs seems to attract a different approach.

  An Emacs package is often high quality, well-thought out, as narrow or as broad in scope as the problem requires, and very configurable should you want to switch some things off or change some behavior.

  The plugin system’s flexibility and the choice of Lisp dialect as language means that even if the thing doesn’t do exactly what you want and doesn’t have a customization option you’d like, you can often get away with substituting your own function here or there to augment things.

• You can use almost all of Emacs’ features both in console mode on a random server and in a nice GUI mode on your desktop. Almost no other editor can claim this.

• Emacs explains itself. I don’t mean it holds your hand or it’s obvious to discover everything, because it’s really not. But there is extensive built-in help: You can ask “what does this key do?”, “what is this function?”, “what things are active in my current buffer?” and many more questions with just one or two keypresses. It also displays any actions that are possible after you press the first part of a key combination, for example, so you can narrow it down interactively.

  The Ctrl+P command palette from Sublime Text (which was directly copied by Atom and later VS Code) goes in this direction as well, but Emacs documentation discoverability goes further. You can explore from a manual written in prose all the way down to the source code if you want, without ever leaving the editor.

• The community on IRC is simply amazing. They have exactly my gnarly, crusty, psychedelic sense of humor. Don’t let this boring blog post mislead you, I love the dumbest wordplay and the deepest cuts and references and especially absurd or surreal humor. There’s plenty of that in there. These people are the antithesis of Discord meme culture. Some of the jokes do fly way over my head, though, because I haven’t read the classics.

  Sometimes they talk about Emacs, and that’s fun too.

• It’s a truly free, openly governed project and has always been. Some people are unhappy with the relatively conservative style of the FSF, but if that bothers you, this is where the powerful plugin system comes in. You can achieve many things with Emacs plugins that other editors can only do in their core. This allows you to be decoupled of Emacs’ own release schedule.

Why not Emacs? #

1. The learning curve really is steep.
2. The single-threaded nature of many network functions will freeze your interface.
3. If you’re a web dev and need a lot of buffers with mixed languages (JS and HTML and whatever is the template language of the week), Emacs might not be best because polymodes are complicated.

You can get around the first point by using a distribution such as Spacemacs, but I was always hesitant around those. Some of them seem to change Emacs so much, it might as well be a different editor.

I don’t want to travel too far down that road because one day I’ll find myself stuck with just a plain Emacs on a server and I’ll be completely helpless. By starting my own config from scratch, I still remember most of the vanilla functions and I could get by in a pinch.

Sticking close to vanilla also means being directly confronted with a lot of archaic concepts like point and mark, a window being a frame and not a window, keys being called something you probably don’t understand (meta, super, hyper; it’s more difficult for people who come from non-UNIX operating systems but it’s still not what’s printed on your keyboard).

You’ll just have to learn these. It can be done in a weekend, it’s not likely to confuse you much after that, and you’ll have a much easier time reading old and new Emacs documentation, so there is a payoff to this.

The freezes, I don’t know what to do about those. Emacs has excellent support for editing remote files using sftp, sshfs, even a remote RPC server via TRAMP-RPC. But something deep in Emacs’ core demands that some network operations block your UI, and this is very painful in an environment with unstable network connections.

By unstable I don’t mean “it goes down often because it’s unreliable” but “I’m not always connected to the right VPNs” and “I’m on the move and swapping between 5G, WLAN and Ethernet”. If you have just one TRAMP buffer open somewhere and your connection goes blargh, chances are you can never recover your running Emacs session, even after everything reconnects.

For a while I made use of a lot of auto-saving and backup files and whatnot to get around the problem, but lately I’ve just given up. If I need to edit a file remotely I usually go back to vim on the server or I spin up an Emacs there if the firewall rules permit pulling in my packages.

So what’s my configuration? #

Everyone’s Emacs config is different so mine’s unlikely to fit you. But if you’re curious:

• LSP support via eglot (built-in). I did try lsp-mode but couldn’t get it to work reliably with Python virtualenvs no matter what I tried.

• Flymake (built-in) for handling diagnostics.

• Virtualenv (and other env var stuff) support via envrc and direnv. With this, when I open a Python file from a dir with a direnv configuration, the env is automatically activated and everything works, including language servers.

• Rassumfrassum to multiplex language servers, particularly basedpyright and Ruff.

• python-black to format a buffer or region using Black.

• Avy and ace-window to easily navigate within a buffer, switch windows, slap some text from here to there, etc. Many, many small niche features in these tools, it pays off to explore them.

• Corfu, Vertico, Marginalia, Orderless to make any sort of autocompletion much more pleasant.

• Consult to get around Emacs and my project more quickly (e.g. via easy access to live ripgrep results, recent files, bookmarks, etc.)

• Shiftjay, my own little package to join lines/regions in the vim way, not the Emacs way.

• Lots of themes by Protesilaos (ef- and doric- themes)

• Vundo for a visual undo tree. Every editor should have this.

• Embark, nerd-icons, rainbow-delimiters and other “smaller” packages that just make life more fun. Very optional.

I feel like I have a good balance of package count and maintainability. I can do everything with Emacs that I used to do with the other editors, and more.

Emacs resources #

These people, blogs, books helped me the most while cobbling together my configuration:

• #emacs on Libera Chat (that’s an IRC channel, not a hashtag)
• #Emacs on Mastodon (now that one is a hashtag)
• lewrker, an Emacs user on another IRC network
• The /r/emacs subreddit, though it has become a bit weird, what with Reddit going through some phase
• Mastering Emacs and random blog posts by Mickey Petersen
• The Emacs manual as served by Emacs Docs (for the nice style and to take some load off GNU servers)
• Protesilaos and his blog posts and videos.

Conclusion #

Do we need to have one? I’m happy with my config. It took months to get it right. I was ready to give up three times. It made me deeply sad when things were broken for several weeks and I couldn’t figure out how to fix them. Configuring an editor should not take this much out of a person. Hence the pregnancy comparison.

Am I happy with the baby? Yeah, for the most part. I can see some of the basic frustrations I had with Emacs slowly going away, too. That’s thanks to Emacs still improving steadily after 50 years, but also because you just get used to stuff and adapt your behavior.

I probably won’t be around in 50 more years, but out of all the editors I’ve listed, Emacs seems to be the one most poised to still be thriving.

LLM statement #

No LLMs, spell-checkers, or writing aids of any kind were used to create this blog post.

Pregnancy disclaimer #

I have no uterus and can’t imagine what it’s like to carry a human baby to term. Of course comparing that to fiddling with a text editor configuration every weekend for seven months is ridiculous. If you have actual experience with pregnancy and take offense at the comparison, that’s surely justified; I just needed a catchy title and no disrespect is meant.