My thoughts about editors in 2020

editor, vim, neovim, atom, vs-code, emacs, intellij-idea

2020-09-07 00:03:00 UTC, by Dimitri Sabadie — feed


I have been trying a lot of editors lately. When I say “trying”, I really meant I spent some time configuring and using those editors. The ones I spent time using are:

The goal of this article is to create a temporal “snapshot” of my views on editors and what I think about the current situation. I have been using vim and especially neovim for more than a decade. I need to explain about my current workflow and what I cherish in editing before talking about each editors. Expect a point of view from a neovimer which is looking around at lots of editors.

This is only a personal workflow / point of view that works well for me right now. It doesn’t mean it will for you and it doesn’t mean a different workflow would be worse.

What I think powerful editing should be

Keyboard layout

I am French and I’m using a keyboard layout that is made to type very quickly in French and to code. With hindsight, since I type more often in English than in French, maybe I should have picked another keyboard layout, but the coding experience in my keyboard layout is really great, so I stick around.

The keyboard layout is bépo. I learned bépo the “recommended” way — i.e. you have to practice typing (« dactylographie » in French). It means that I use all my fingers to type on a keyboard, and that each key on the keyboard is assigned a single finger that will press it. That helps a lot with muscle memory and to reduce wrist pain (my wrists barely move when I type on a keyboard), among other things. The typing speed is a side-effect of being accurate and having good comfort (if you are curious, I’m pretty fast but there are faster people — I type at around 120 to 130 words per minute). Because I think the speed doesn’t matter when programming, I think the most important part to remember here is the comfort: the wrists don’t move and my fingers fly around the keyboard, whatever the speed.

I think a modal editor is superior, for various reasons. The first one is that I truly hate having to use a mouse for something that can be done without having to move around hundred of pixels with your cursor and clicking on buttons. For instance, running an application, on my current machines, is simply typing alt d, the name of the program (I typically use completion, so I never type fully the name of the program) and hit enter. All this without moving my hands from the keyboard. And I do that for programs like firefox, kdenlive, etc. but for terminal applications, I simply type and complete them in my terminal, which I open simply with alt return.

So, using a mouse to move around a cursor in an editor feels like completely suboptimal to me, especially because we write code (i.e. we type on a keyboard) most of the time, so moving around with the mouse implies several back and forth movements between the keyboard and the mouse. Maybe you don’t care and it’s cool to you, but to me, this is truly horror land. I feel very uncomfortable when doing this.

Also, modern editors that are not modal typically make people move by using the arrows keys, which are either far on your keyboard, or — like my keyboard, a 60% home made one — not in direct access and then require a function key to enable them.

So that’s the first reason why I like modal editors. They make a smarter use of your keyboard for simple yet recurrent features, like moving around — e.g. h j k l. The second reason why I like them is because of the facts they have a completely new mode for non-modal editor (i.e. the normal mode), you have a whole keyboard / lots of keys to bind actions to and do lots of things people usually do with the mouse. Being able to split an editor into several buffers, move around the buffers, go at the beginning of the paragraph, search and replace, register actions into macros and replay them, etc. All this without even moving the wrists. The learning curve is steep if you’re used to the mouse, but once you’ve passed the mental barrier, really, and this is a personal opinion, but I truly think that using the mouse again after that feels like handicap to me.

How I like to move around

When I look at people coding, I see several kind of programmers:

I think that represents 99,9% of what I see people do. Obviously, you will get that I don’t belong to the second set of people… but I don’t really belong to any, actually. How I move is, I guess, convoluted for most people and I know some people won’t understand how it can feel. I use h j k l and all the motions from vim described in the third group (and even more; I full lecture of four hours would be required to explain all of them :D), but it all depends on the distance I need to travel. If my cursor is on a word and I want to move to the beginning of a word located very closely to my cursor on the same line, I’ll simply type www if it’s three words apart (or 3w if I’m feeling funny). If the distance is higher, I use a tool called [EasyMotion].

Easymotion really is a wonderful tool. The idea is that it has several modes, depending on the kind of move you want to perform:

The way I typically do it is by mapping the three modes to <leader>l, <leader>w> and <leader>c (in my case, <leader> is the space key).

Typing SPC l in my current buffer results in this:

EasyMotion lines

Typing any highlighted character will make my cursor jump to it. The same applies for words, with SPC w:

EasyMotion words

For the character mode, after pressing SPC c, I have to press another character (the one I want to jump to). Let’s say we want to jump to a # (which is not part of words): SPC c #:

EasyMotion characters

This way of moving is not intuitive at first, but once you get used to it… it’s a must have.

All the other modal candies

Among all the things that I like about modal editing, here is a non-exhaustive list of features I expect to have around my fingers:

It would take too much time to list everything, but the main idea is: I need the modal features when editing code.

The editors

So let’s talk about the list of editors I mentioned in the preface. The idea is to give my own opinion on those editors. What I like about them regarding the way I like to edit code and what I think is missing.

neovim

I currently use neovim in its TUI version, because it’s the most stable, fast and easy neovim experience out there so far to me. I have tried several GUI versions but never found what I was looking for — the main reason being that they pretty much all of them use Web™ technologies, and it’s a hard no to me. I think I should elaborate a bit more about that last point.

Why not using Web tech:

My neovim setup

So I use several plugins that I’m going to describe. I think it’s important that people know about all those because, in the collective mind, people still think vim / neovim are editors from the past. Well, not really.

What I like about neovim

What I dislike about neovim

IntelliJ IDEA

So I won’t going to be able to talk too much about this one, because I have only started using it at work (community edition). I’m using the vanilla one, with few modifications to none. I edit only Java with it.

What I like about IntelliJ IDEA

The Java support is truly flawless. It does a lot of things for you, and among them, I was really impressed by:

What I dislike about IntelliJ IDEA

VS Code

So this one is an important one, as it’s Microsoft’s take on editing. Everybody seems to love VS Code, and I get why. The UI is slick and fast — for a Web-based editor… ;). LSP support is obviously premium and flawless. It has a lot of community plugins, themes and integrations. For most part, even though it’s Web based, I have been enjoying it.

What I like about VS Code

What I dislike about VS Code

emacs and DOOM emacs

I have been using emacs lately (vanilla) as I saw a colleague using DOOM Emacs. I’m putting both in the same section as they are pretty similar. The way I see emacs and DOOM Emacs could be summed up with one word: united. I don’t know how they do that, but all plugins blend so well with each other. I’m using the ivy interface for completion and fuzzy search, and everything is so… well done. The UI is gorgeous, themes are awesome (I like the default dark theme, DOOM One), the editor is pretty fast — still slower than neovim to me, especially when scrolling, but still much faster than a Web-based editor.

What I like about emacs / DOOM emacs

What I dislike about emacs / DOOM Emacs

atom

I’ll finish with atom, GitHub’s editor. I remember my first reaction when running atom for the first time was: “Woah, that’s a pretty editor.” The default colorscheme, One, is a universal colorscheme everybody knows. There are have been so many forks of it in so many different editors.

atom looks a lot like VS Code to me, but is a bit prettier in its UI — I do prefer atom’s UI to VS Code’s. The UI is slick and very clean. You can find a lot of extensions / plugins / themes, from LSP integrations to Markdown previews and Vim modes.

What I like about atom

What I dislike about atom

Wrap it up

When I started coding, I remember of people talking about IDE / editor wars. Today, as I have tried a lot of editors, I can say that there’s no such thing as an editor war to me. All editors have drawbacks and picking the right editor is often a matter of taste and personal experience. I’m a keyboard lover (I make my own keyboards) and I truly love typing — not necessarily code, hence it was pretty obvious to go to emacs and vim back then (I actually started coding in emacs). Several years later, I joined the vim side and neovim. It’s only one year ago that I started looking at emacs again to see what has changed. And oh my. So many interesting things out there!

What I like about testing editors is that each and every editor has at least one killer feature no other has:

Spending some weeks in all those editors made me realize something about vim / neovim: I don’t necessarily think I should be using them, especially since I have used emacs / DOOM Emacs with its Evil-mode. Today, my thoughts revolve around the idea that a good neovim client could be a gtk application like emacs: slick, united, with great defaults and full support of neovim features, with support for gtk floating windows and popups (as it’s native in neovim and feels a bit hacky in TUI). We already have great plugins for things like git (fugitive / vim-gitgutter), completion and syntax highlighting with coc.nvim / vim-lsp / vim-treesitter. The only piece that is missing to me is a great GUI to leverage the “hacks” we have to do in TUI to actually use real popups, “balloons”, etc. Once we get a decent neovim GUI, I think I will have found my favorite editor of all time.

Until then, I’ll stick around neovim TUI as it’s what is as close at what I would like to get. I hope this article will have given a bit of hints about what a vim / neovim enthusiast might expect from a modern editor. And I say a vim enthusiast, not all of them. We all look for different things and I truly thing we live in a wonderful world with all those editors out there. They won’t fit for everybody, but everybody will find one for them, and damn, that’s a pretty good conclusion to this article.

Feel free to tell me about what you think about your editor, whether there’re things you dislike about it or what you would like to see appear in it. Keep the vibes!