What I Want in a Text Editor

March 11, 2025 —

I made the decision early last year that I wanted to learn either Neovim or Emacs. I ended up actually learning both, though I'm still definitely not an expert in either.

One of the reasons I had for this is that while I still really like the Jetbrains IDEs, I've been growing more and more weary as the years go by of the yearly update cycles that the tech industry as foisted on us all. Even though I generally like Jetbrains' stuff (I've been a paying Jetbrains customer since 2012), they are not exempt here. I generally upgrade to the latest versions on a lagging schedule that is many months in length. This is because I don't often feel like their new releases add much of value ... usually in fact they add new annoyances disguised as features that are often turned on by default and have nagging notifications or other pop-ups associated with them. But they gotta keep doing this I guess as how else are you going to keep the sales coming in. The line has to keep going up after all, right? Ugh.

I don't always need a heavy-weight IDE though, and Sublime Text has been my preferred choice for when I just need to quickly edit some text, config file, standalone script, etc. Sublime Text is super fast, handles large files well, has great multi-cursor support, decent-ish plugin ecosystem and I'm happy overall to have been a paying customer of theirs since 2013. (Additionally, I'll add that I've been extremely happy with their Git GUI too, Sublime Merge which is my day-to-day Git tool of choice. I thumb my nose at all of you Git CLI snobs!)

However, one thing that changed for me in the past year and a half or so is that at work now I find myself spending a lot more time in a terminal and working with files on remote servers. To be clear, I'm not talking about remote development (that topic actually deserves its own separate long-winded ranty post, but for now I can say that thankfully I just don't have to do that at all). I'm instead talking about editing config files and other standalone scripts and such things on remote servers, as you would when doing system administration type tasks.

Jetbrains editors are obviously a no-go here, as it's not really intended for that use-case. Sublime Text is also sadly, not good for this purpose either! It doesn't have any built in remote editing features, and none of the plugins I've seen fill this void either. Mounting a remote file system over SSHFS and then trying to use Sublime Text with the remote files that way is a shockingly poor experience, to the point where the editor grinds to a halt if you point it at a remote file hierarchy that is somewhat large. This is because it's trying to index everything (which you only have insufficient control over) and the extra latency of a remote file system takes its rather extreme toll.

At this point I find that people will say one of two things, usually:

Why Not VS Code?

No.

Ok, fine, here's a longer reason: Noooooooooooooooo.

But really, why not?

  • I don't care for Electron-based solutions. I don't personally intend on supporting development teams (by using their software) who, on their own accord, decide to use Electron. We've got so very much computing hardware resources at our disposal today, and we're apparently stuck with Electron as a cross-platform foundation for desktop software development because ... why? I can't think of good answers to these questions. All I can think of are excuses that the tech industry hides behind about why they think it's needed and is a "good thing." We could definitely do better if we put our minds to it. But we don't, because we're lazy, apparently, I guess.
  • I don't particularly like that there seems to be a weird "monoculture" slowly forming around VS Code, where many people seem to just assume that everyone else is using it too. So, for example, you end up in situations where someone put together a project that assumes the use of devcontainers because VS Code has good support for it ... but, if you're not using VS Code, you're shit out of luck because nothing else out there has an equivalent level of support for it.
  • While the remote development support in VS Code is overall well regarded, it is (in my anecdotal experience at least) a semi-frequent source of server troubles where run-away vscode-server processes or processes spawned by it (such as rg) hog tons and tons of server resources even after the developer has disconnected and gone home for the day! You don't have to spend too long searching for this problem to find system admins grumbling about this. It's not a new problem, and apparently it's still not a solved problem either.
  • At the end of the day, in my opinion, VS Code is not a feature-equivalent substitute for the Jetbrains' editors if you're working with languages like Java, C#, Rust, or others of that sort (though, it's not terrible for those types of projects either). And it just feels extremely heavy for an editor for doing other smaller edits with. See: previous Electron complaints.

I'll admit that there's more than a little personal bias in the above reasons. That's fine, we all have our personal preferences.

Vi/Vim for Remote Editing

So, what do I think about people just telling me to use Vi or Vim on remote servers?

This can definitely be fine, and certainly I do it often enough. Although I will admit that I take a perverse pleasure out of using nano especially when I'm pairing with someone else on a task just to see if they scowl or scoff at me. It's fun, I highly recommend doing this. And I just have to take this opportunity to say that if you're a person who scoffs at someone else for typing nano, I'm sorry, but you are a very shallow person indeed.

Anyway, often times you're dealing with a very complicated hierarchy of files on a remote server and vi/vim/nano just isn't really cutting it for you. This happens to me quite a bit actually in recent years. I know some people deal with this just fine with nothing more than vi/vim and are quite happy with it. I'm just not one of those people.

Neovim and Emacs

So this brings me back to wanting to learn another editor that gives me a very strong level of control over its configuration and functionality, and I feel like Vim/Neovim and Emacs are the poster children for this. Plus they both work directly in a terminal if you like and could even be installed remotely on a server if you really wanted (though I don't think I'll ever go to that extent myself).

Neovim

I've never been big on Vi or Vim. Modal editing has always seemed really strange in a "wtf" kind of way to me.

So, it's funny to think that actually last year I started learning Neovim before Emacs. I made that decision because like it or not, when you're dealing with a remote server, you're practically guaranteed to have vi available, and very likely vim. I've actually dealt with a lot of servers where nano was not installed much to my chagrin. So I felt that it was about time that I got better acquainted with the Vi/Vim-style modal editing.

I decided to go with Neovim specifically because it's a somewhat more modern take on Vim, enhancing it with stuff like "better" (subjective, I guess) defaults, adding Lua as an alternative to Vimscript, built-in LSP and Tree-sitter support, etc.

I will say that it's been a journey. There's been definite high's and low's along the way. There's been many frustrations and other times where I've definitely sat back and said to myself "you know what, I'm glad I put in the time to learn this." In fact, I will say that I'm writing this post with Neovim.

I can definitely say though that I still don't like modal editing. I'm getting more accustomed to it. But I don't like it. I don't think it makes me faster. I don't really feel like I'm a person who benefits from being able to navigate around my editor or IDE at light-speed anyway. For me, the bottleneck is always my brain and thinking about what I'm doing or need to be doing, not how many key-strokes or mouse movements I'm required to make.

I think what bothers me most about modal editing is how often I forget what mode I'm in (and that I still cannot train myself to hit ESC nearly as much as I should be hitting it to protect myself from exactly this) and start typing and then ... chaos ensues and who knows what state Neovim gets into before I realize what happened. This happens a lot to me because often in my day-to-day work I am referencing stuff in other windows (such as documentation in a browser, or other terminal windows, etc) and will be shifting focus around back and forth. I truly don't think I'll ever learn to "love" modal editing, but I am getting better at it slowly, bit by bit. And to be fair, I can understand why some people really love it.

The other thing that bothers me about the editing experience in Neovim and Vim is the use of the H, J, K, and L keys for cursor movement. This isn't required mind you, as modern keyboard arrow keys also work for basic cursor movement and you can optionally create your own keymaps for the remaining things (like switching between windows) if you really wanted. I don't go that far myself, but I do still refuse to use H, J, K, and L for basic cursor movement. I imagine a lot of Vim users would scowl at me for this and perhaps rightly so. The main reason I don't convert over, is because I am not a typical keyboard typist. I don't use the standard "home row" technique. I did learn how to type this way back in school during the 90's but I never liked it. I can very effectively "touch type" but I do so with only 2-4 fingers that move around the keyboard. I'm so accustomed to this over so many years that I can type like this pretty quickly and while looking directly at the screen the entire time just fine. Using the H, J, K and L keys for navigation seems to be something intended to feel natural to people using "proper" typing techniques. To me it just feels bizarre.

A big win for Neovim is that it starts up lightning quick, even with all my plugins configured (after a very brief time playing around with LazyVim, I settled on DIY'ing my own config using kickstart.nvim as a base). It also works perfectly in a terminal, of course. I've had a pretty good experience with remote editing complex file trees remotely over an SSHFS mount with Neovim too. The latency can be noticeable, but it's definitely good enough for me.

Other big win for Neovim include the aforementioned built-in LSP support. When you combine this Mason the experience really improves. I still think Neovim hasn't hit the "sweet spot" with all of this though, as you still need a surprising amount of manual Lua configuration and plugin code to get LSP support at what I think most people would call an "acceptable" level. I think this is something that Helix is doing much better at from what I understand (the out-of-the-box configuration and experience).

Emacs

I'll admit that I'd had some level of interest in learning Emacs since way back shortly after starting with Clojure. At the time, I remember most Clojure developers recommended Emacs, but I felt it would've been unwise to learn a very alien-looking programming language and learn a fairly alien-looking and behaving editor at the same time. So, I ended up using the long-since-dead Eclipse Counterclockwise plugin instead for Clojure development. This wasn't super great as I'd always hated Eclipse. However, I only endured for a couple years until Cursive released.

But now that I've long-since gotten over the "parenthesis-phobia" that seems to be an obstacle to getting new people to try Lisp-like programming languages, I look at Emacs in a very different light. An editor that uses Lisp to configure and extend itself. And as a bonus, it doesn't force modal editing on you. Sign me up!

That all said, I really, really, really, really wish there was something like a "NeoEmacs." That is, something in the same vein as Neovim for Emacs: a cleaned up, refactored Emacs that has some more "modern" defaults out of the box, and just otherwise jettisons at least some of the "odd" behaviours that are holdovers from decades past. I don't really ever expect this to happen though.

To me, Emacs feels like "death by a thousand cuts" in a lot of ways. A lot of the language modes have their own editing settings, which makes doing stuff like configuring it for tabs (Yes, I am a tabs-person. No, you are wrong for being a spaces-person and I will fight you!) a frustrating experience. Plus stuff like the tab key mapping out-of-the-box being overloaded to both, some automatic "indent to the proper indentation level" (indent-for-tab-command) functionality and being the completion key can be a little frustrating and strange at times. The aforementioned "indent to the proper indentation level" functionality wouldn't even be so bad if it wasn't of somewhat dubious quality. I've gotten into a situation on multiple occasions where hitting the tab key did nothing because the current language mode in Emacs had some incorrect idea about what the indentation level should be on the current line. Very frustrating.

Another disconnect I have with Emacs is that it doesn't always feel great to use as a kind of "ephemeral" editor. That is, I'm in a terminal and I need to edit a file quickly and so I type in emacs /path/to/file. This obviously works but Emacs doesn't start up very fast once you have a few plugins installed. It's not the end of the world. It certainly starts up significantly faster than VS Code, or any of my beloved Jetbrains IDEs (which are all giant pigs). But it is very noticeable to me if not just because I'm using a lot of Neovim concurrently, and Neovim does start up nearly instantly also within a terminal. So it just feels a lot better to use for quick edits.

And I'm not really sold on Emacs as something that I just keep using for all kinds of random things beyond text editing. Yes, I know people use Emacs to read their email. They use the built-in Emacs shell support to do all their terminal stuff too. Soooooo many people gush over Magit. I'm not interested in a "do everything" app. I don't want to try to shoehorn everything into Emacs "just because." I'm only interested in it as a text editor (and possibly as a lighter "IDE" of sorts). That's it. No, you're not going to convince me otherwise.

That all being said, I actually do fully intend to keep on using Emacs and learning it more and more. One thing I really love about it is the minibuffer combined with vertico, marginalia and orderless plugins. This really vastly improves the in-editor discoverability of things. If you don't know how to do something but suspect there is probably a command for it, you can easily search through the available commands from M-x. Or search for variables related to settings you're interested in while being able to easily see what their current value is with C-h v. Plus the actual full help pages for all of this stuff are great and can be greatly enhanced by just a couple more plugins if you so desire.

Emacs also now has (as of some very recent version which I don't remember at the moment) out-of-the-box support for LSPs and Tree-sitter. Though both of these feel very early and the experience feels far better in Neovim I think currently. I think Emacs itself as well as the supporting plugin ecosystem for these things will improve in time, but right now a lot of things feel rough around the edges.

I've been purposefully vague on some of my criticisms for Emacs here because I fully recognize that some of my difficulties and other general criticisms so far could well be just due to my limited experience with it to date. I suspect in a years time some of my opinions will change and/or improve, but who knows.

I've found it to very reasonable to use for editing files remotely, again using SSHFS mounts. I know that TRAMP is a thing, but I've not dug into it a whole lot yet (I've read a lot of mixed things about it so far). I've found that most of my SSHFS difficulties were resolved with the following custom command which I manually run via M-x before I switch into an SSHFS mounted file-system with Emacs.

(defun gered/setup-for-sshfs ()
  (interactive)
  (setq vc-handled-backends ())                       ;; effectively disables version control support
  (remove-hook 'prog-mode-hook 'lsp-non-interactive)  ;; disables lsp-mode
  (setq after-focus-change-function (lambda ()))      ;; helps further reduce "random" file I/O
  (message "Finished setup for SSHFS use"))

The goal of all of the above is to disable a lot of extra file I/O that Emacs would otherwise do which would significantly degrade the experience of using Emacs for files on a remote file-system.

Others?

Zed

Somewhat recently in some circles, there was a lot of interest/hype surrounding Zed. I did actually try this for a while and it does seem promising in a lot of ways. It is quite speedy and gives a really good out-of-the-box impression.

However, I'm not super excited about how it seems overly focused on collaborative editing ("multiplayer code editor"). I guess there are some teams for whom this is a really compelling feature, but I really wonder what proportion of people are really excited about this stuff. It certainly doesn't interest me whatsoever.

Furthermore, I'm worried about the potential future enshittification both from the focus on built-in "AI" functionality as well as the fact that the team developing Zed is being backed by investors who will no doubt want to see some sort of return eventually.

For those reasons alone, I don't really intend to spend any time with Zed. Perhaps, since it is (so far) fully open-source, maybe if it gets forked in the future, I might take another look.

Helix

I've not tried this at all yet, mostly because I'm waiting for it to have actual plugin support (which is apparently coming eventually), but Helix does look interesting, offering a more "modern" out-of-the-box experience and would seem to address some of the config complexity concerns I have with Neovim and Emacs.

It sounds promising, and despite the fact that it is an editor designed around modal editing, I do intend to give it a close look in the future.

Alright, So How About Getting Back to the Title Of This Post?

Alright, so now that I've rambled on, somewhat incoherently perhaps, about various editors I've tried recently ... what do I actually want in a text editor?

I don't think I'm actually that difficult to please, really. There's nothing earth-shattering in my wish list.

In no particular order:

  • No forced modal editing. I don't want to have to worry about whether I'm in insert, normal, visual or whatever-the-fuck-else mode. I don't mind if support for modal editing is optionally included, but I just don't want it forced on me.
  • Mouse support. I think a lot of people forget that we perhaps spend more time reading code than writing code. I often find it easy to go around reading through a lot of code by casually sitting back and scrolling through it with a mouse, perhaps with a coffee or other snack in my other hand. I don't want to feel like some second-class-citizen because I sometimes like to use a mouse to interact with my editor. That said, being able to turn off a lot of visual/UI elements in the editor to get a very minimal look is important too.
  • Works in a terminal. It can have a fancy GUI mode (like Emacs does), but it should also have a fully-functional Terminal mode.
  • LSP support. This is clearly the way things are going into the future, and I would agree that this is a "good thing" overall. Certainly the results from LSP support has brought significant improvements over traditional code indexing and tagging that many editors used to do. So, this should be built in, and ideally and optionally provide you with something like the Neovim "Mason" plugin experience to more easily install and update the actual LSPs that you'll need.
  • DAP support. This also obviously implies some ability to run a debugger integration.
  • Multiple cursors. This is one of the biggest things I miss from Sublime Text. Such a handy feature in oh-so-many situations.
  • Fast startup. I don't want to have to wait multiple seconds to load, especially when I'm not opening the editor up to a big project. If I'm just opening the editor up to a single file, it should be quick.
  • Remote editing. I actually just care about being able to do remote editing. I don't really care about full on remote development (that is, building/compiling and remote debugging, etc). Though I suppose if support for those were present too, I wouldn't necessarily complain. But I mention this distinction because I don't know if I necessarily care or even want this "remote editing" support to necessitate the use of a remote agent. I can see that that brings with it some obvious benefits, but I also have to believe that built-in editor support for something like SSHFS could also enable some further optimizations to improve the experience overall. And an agent-less remote editing experience feels like a "holy grail" of sorts, at least to me.
  • Good, speedy fuzzy-finding support. This should be for things like searching through text but also for matching files, buffers, and more. Things like Neovim's Telescope plugin comes to mind, which has the ability to hook in to all kinds of things to fuzzy-find through. This is a really powerful feature.
  • Fully customizable window splitting. Again, just like Neovim and Emacs, as well as many other editors.
  • Directory tree view. Nothing much more to say here. Pretty common these days.
  • "Project explorer"-style directory tree view. This should be separate from the "standard" directory tree view. But otherwise, this should match the "Project Explorer" pane that Eclipse has, which is probably the only feature I actually miss from Eclipse. Also the Treemacs plugin has this too.
  • Plugin support. Obviously no editor can be expected to "have it all" out-of-the-box. Being able to extend it through a fully featured plugin API is really the only way to have even a chance at satisfying everyone. I would probably suggest some Lisp or Lisp-derived language here for plugins makes sense, but not a hard requirement.
  • Plugin package manager. I think this is perhaps the biggest faux pas that Neovim has made. Include support for a package manager to help everyone manage their plugins. It doesn't have to be a requirement in order to use plugins. If someone really wants to do it all themselves, then sure, let them. But just have one that is based on Git repository URLs or something simple like that.
  • Multiple syntax/language support. This one I think should go without saying, but I'll add a separate bullet for it just in case. Ideally this support would also be able to be extended by the plugin support.
  • Fully introspectable and programmable. This is more along the lines of Emacs I think than Vim/Neovim, but I suppose both have it to a certain extent. I suspect this is just better in Emacs due to it being based on a Lisp, but I might be wrong. Either way, I want to be able to fully inspect/browse/modify the running editor's state from within the editor. I should be able to toggle variable values on the fly from within the editor. I should be able to run arbitrary functions written in the plugin language that the editor supports to do things. I should be able to map functions I've written to arbitrary key bindings. All the built in editor functions, variables, etc should have built in help pages. I could go on, but you probably get the idea by now.
  • Command palette. Very much an extension of the previous point, but this would be similar to M-x in Emacs, or Ctrl-Shift-P in Sublime Text. A way to bring up a "command prompt" of sorts to run anything in your editor, where the commands can be fuzzy-searched/matched.
  • Version control support. This is actually just a "nice to have" to me if I'm being honest. I say this because the only thing I ever use an editor's built-in version control support for is just to quickly see what files I've modified and what lines within those files I've modified. For all other version control tasks, I always prefer using an external Git client.

I think that's pretty much everything I care a lot about.

You'll notice I didn't say anything about "AI." Or collaborative editing. These are not accidental omissions, I assure you. They are very much intentional.

Also, just to be clear, I don't think any of this would replace full-blown IDE usage for me. Just like I can't personally imagine working on a full Java or C# project in Neovim, Emacs or Sublime Text (although I'm well aware some people do just that), I wouldn't expect my "dream" text editor to do so either. I don't see it as replacing that. Full-blown IDEs would still definitely have their place. This would just be for my "everything else" text editor.