It’s 2019. Why don’t we have good code editors?

For a while now I’ve been trying to find the perfect code editor for me to do my work. And yes, I’m well aware that finding the perfect editor can certainly sound impossible, but should it be in considering today’s software? 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 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 not 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 cannot fully support that style of editing because the editor wasn’t built with that type of editing in mind, which 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, but it 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 that’s out there. 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 a good editor 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 at once, multiple selections, editing multiple lines that aren’t necessarily in sequence and at different columns, 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:

  1. Searching for extensions
  2. 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 implementation to see what it does makes it so much easier to work with code! You don’t have to remove yourself from your 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.

Published by Kristófer Reykjalín

Code Charmer working for Automattic.

11 thoughts on “It’s 2019. Why don’t we have good code editors?

  1. Excuse me if this is a somewhat ignorant statement. But for your modal editing first, everything you listed there can be done in “normal” text editors through shortcuts?

    I’m a vim basic user (only use dd, and then insert mode editing and search) because i usually only use it for editing Configs, so i don’t need deeper knowledge, but it certainly seems to me learning shortcuts + moving to a Jetbrains IDE (or even vscode with a few more shortcut plugins) would solve your core problem.

    Moving lines, duplicating lines, removing lines are just a simple shortcut away, searching whole project is just double shift, refactoring a variable/method/function/class/etc is just one shortcut and it’ll apply across the project, go to definition is just middle mouse click / shortcut, so reading is super fast.

    Maybe not your perfect solution, but sounds pretty close to your requirements? Only problem is launch speed is garbage, so, fantastic for project work but not great for one off files

    Liked by 1 person

  2. I would like to say that I see a little flaw in one phrase of yours:
    «but that’s not how anyone works today. Using the mouse is comfortable, intuitive, and easy»

    I don’t agree (I respect your opinion, but I don’t agree with you).
    Using mouse is not easier. It just seems easier when you have no idea on how to reach some tools/command/options, or if the UI is not well designed (or to be fair, when it is not designed for your needings).

    What I mean is that if you work 10h per day on code, having all functions reachable through clear and specific keystrokes or commands is way faster than mouse and what you gain is not milliseconds, but minutes or hours speaking just of attention (not moving hands, eyes, head) not to mention real time saved by doing tasks in a quick way.

    Don’t forget that coding does not mean just writing code.

    An answer to your very question is that, speaking of intuitive tasks, what’s intuitive for an european can be not intuitive for americans or asians, hence you simply cannot have something that pleases everyone.

    Your analysis is not wrong. Question that led to your analysis is, imho.
    What I consider a good editor can be bad for you and viceversa.

    That’s, for example, why I personally hate IDEs. They tend to be distracting, to drive you through the rails of the IDE author’s minds. You must do the job twice: do your job and then do it again in the way that was chosen by IDE’s authors.

    Last, but not least, I know that an IDE environment is “pretty” because it “just works”, but since you have to redesign everything to fit the IDE’s concepts, at the end you loose a lot of time. (and they are not easier to use)
    On the other hand, something organized with external tools, is harder for starting, but usually pays you back in the long.

    One of the biggest mistake is to take IDEs as example of good software. They are not. They are awful for working.

    Please take this as my personal opinion.

    Liked by 1 person

  3. > 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!

    Vim, of course, supports both – mouse support has vastly improved over the last few releases, and there’s plugins for file sidebars (NerdTree e.g.). Though, yes, working with vim plugins remains a pain in the ass, and discoverability remains close to zero.

    Liked by 1 person

    1. mouse support has vastly improved

      It has been vastly improved for sure, especially with the likes of gVim, but it will never reach what applications designed with a GUI in mind can do. Vim wasn’t designed to be used with a mouse, so it’s a suboptimal way to use the editor.

      and there’s plugins for file sidebars (NerdTree e.g.)

      This is very true! I think for me, the issue is more about out-of-the-box functionality, discoverability, and installation.

      Though, yes, working with vim plugins remains a pain in the ass, and discoverability remains close to zero.

      This is exactly my problem 🙂 . It’s difficult to find these extension if you don’t know what you’re doing. Installing Vim extensions is an absolute pain, and you could argue that for a modern code editor, a project hierarchy view should be built-in, not installed through an extension. It’s very useful to have one, and no real downside to adding it.

      Like

  4. Some editors support editing multiple lines at the same time, usually by setting the cursor using alt+shift+left click.
    In IntelliJ you can set multiple cursors in different locations.
    In the VS family you can create a “box” selecting the same columns on different lines.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: