I’ve spent a long time trying different code editors, trying to find the perfect one for me. And yes, I’m well aware that finding the perfect editor can certainly sound impossible, but should it be in today’s software ecosystem? I don’t think so.
To be clear, this rant—let’s be honest, this post definitely is a rant—does not propose any solutions for the issues I have with today’s code editors. Instead it seeks to point out what it might take to create a good code editor.
I’d also like to point out we have a lot of great text editors! Just not text editors that are also great code editors.
My frustrations with today’s code editors
The most limiting factor for my choice of code editors is that I need modal editing. After learning how to use Emacs, and then Vim, I can’t imagine going back to the typical non-modal text editing. These editors make it much more comfortable to edit text (and code), and ruined every other way of editing for me.
Now when I try a new editor or IDE the first thing I do is find a Vim emulation extension. Usually, the extension can’t fully support that style of editing because the editor wasn’t built with that type of editing in mind. That lack of support for modal editing eventually makes me frustrated enough to go back to Vim.
I will then use Vim for a couple of days, trying to set up a good environment for what I need. That inevitably fails and I go back to using an editor like VSCode, that has a “good enough” Vim emulation plugin.
I’ve even gone so far as to try wrappers for Vim like Oni and neovim-gtk, but there are always some issues. Inevitably there will be something that makes it so unappealing that I go back to something else like VSCode.
And I hate that. I don’t like using VSCode—I don’t hate it either—but I’m stuck with it because it’s the best editor available. I don’t like the Vim emulation extension, because it’s often slow, and it doesn’t perfectly replicate the utility of Vim. The best Vim emulation extension I’ve come across is – oddly enough – in QtCreator. If only I could use QtCreator for everything…
What I think good code editors should have
Modal editing first
Modal editing should be the first priority; “normal” editing should come after.
Me, myself, and I
Modal editing makes repetitive tasks while editing code so easy to perform. Now, you might be thinking “why would I want to repeat editing tasks while writing code?”. Well, you won’t want it for writing code, you’ll want it for editing. Deleting multiple lines, writing on multiple lines simultaneously, multiple selections, etc., etc.
Besides, “normal” editing is just a mode in modal editing. If you don’t want the modal editing enabled, just disable it. The editor already supports a normal editing mode—that’s how you write most of the time after all—and that should make this configuration trivial.
Editors that do this well are editors like Vim and Kakoune, and—in my opinion—Emacs, but to a lesser extent.
A modern, graphical UI
Terminal editors are out of date. By this I don’t mean that they’re obsolete; I mean their user experience is lagging far behind modern standards. Using editors like Vim and Emacs is not a good experience for the user. The user interface sucks.
I know there are some crazies out there that do everything in a terminal—I mean have you heard of the operating system called Emacs? It’s great, but despite being decades old, still lacks a decent text editor. In all seriousness though, a terminal does not a pleasant user experience make.
You’ll see many Vim/Emacs users argue that you’re faster by getting used to working only with the keyboard to control the UI. Sure, you might gain a few milliseconds in specific cases, but that’s not how anyone works today. Using the mouse is comfortable, intuitive, and easy. Using a terminal editor that doesn’t properly support doing everything with a mouse just doesn’t hold up in today’s environment of graphical software.
Of course, when a terminal is all you have, these editors are amazing. But that doesn’t change the fact that the UI is horrible, and far from being modern.
Just look at editors like Atom, VSCode, and Sublime Text. All of these editors come with excellent UIs that make editing multiple files—working on a project, not just a file—an easier experience. The way these editors achieve this is through graphical representation of the project hierarchy—the file sidebar—and many other quality of life improvements—like being able to use your mouse!
Support user made extensions
Most text editors have this today, but making extension development easy, and making it easy for users to find and install extensions, is a tricky problem to solve. VSCode and Atom have clearly figured out a way that works for those editors. It’s easy to search for, and install, any extension you might want.
Relative to those editors, Vim and Emacs make this very difficult. You need to either install a package manager, and then the extension, or install every extension manually. The process is a pain, even when you get it right.
When it comes to extensions the following tasks must be easy:
- Searching for extensions
- Installing extensions
An easy way to search for extensions is important because easy discoverability is the key to getting users to use extensions. Easy installation—as in no more than 1 click after finding the extension—is equally important so users will not only search for extensions, but actually use them.
It is, of course, important to design the text editor with all this in mind, and some way to allow extensions to interact with the editor.
Smart auto-complete
This is simple. I want IntelliSense everywhere. Built in. Is that so much to ask?
Peek at implementation/definition
Being able to peek at a function’s implementation makes it so much easier to work with code! You don’t have to remove yourself from the current context to find another file, locate the function, see what it does, navigate back to where you where, and get back to work. IntelliJ really has this one figured out.
Fast and responsive
I don’t mind Electron apps, when they work properly and feel responsive. I happily use programs like Simplenote, Tutanota, and Signal all the time, because they don’t feel sluggish and unresponsive.
Programs like Spotify, Atom, and VSCode however, do feel sluggish and unresponsive at times. It takes a while to load large files. Scrolling halts. Loading the syntax highlighting takes a while. It just feels slow. Not to mention they also use a lot of memory and system resources, even more so than your average Electron app. If they have access to all of that memory and computing power, surely they should be able to run without lagging right?
All of these should come out of the box
I’m sure I could spend days setting up the perfect Vim environment, but my question is: Why should I have to do that? Having all of these come out of the box shouldn’t be that hard in 2019. Some editors have perfect implementations of at least one of the features I want, so an editor that has all of these is clearly not an impossible feat. Why has no one made one yet?
There is hope
I’m actually very excited to see where new editors like Xi and Oni2 will end up. Specifically I’m actively following the discussions surrounding new frontends for Xi, as well as their open issue on modal editing.
I’ve even thought about just doing this myself, but so far I haven’t found the motivation and time to actively work on a big undertaking like creating a text editor I like.
I can only hope someone will see the light and save us all sometime soon.
Leave a Reply