The jungle of code editors

Today I want to tell you about my journey on the broad topic of code editors, which a lot of people handle almost religiously. IMHO it is comparable to the subject of operating systems and the three major worlds of Windows, Mac OS and Linux. As Linux enthusiasts can relate, the question of the right Linux distribution is again a very complicated topic itself. Whether it is Debian, RHEL, Fedora, Ubuntu, Arch Linux, Gentoo, Open Suse, Elementary OS, Manjaro (Heavy breathing), Slackware, Knoppix or any kind of other distribution, everyone claims to be in possession of the ultimate distribution. In this context I want to refer to DistroWatch in order to give you a brief impression of the huge Linux family tree.

Comparable to the challenge of finding the perfect operating system, from my point of view the question of the ultimate code editor should be added to the list of Millennium Prize Problems as well. Joking aside: The global players here are Vim, Emacs, Microsoft Visual Studio Code and Sublime Text. Let me give you an impression of my personal experience with each of them.

Vim

I totally love Vim. And I always will. For my readers who are not aware, Vim stands for Vi IMproved and is a text editor program for Unixoid operating systems. It was first released in 1991, designed for use both from a command-line interface and as a standalone application in a graphical user interface. At first glance Vim is really everything except usable. There are StackOverflow topics on how to legitimately exit the editor. I think this shows that Vim has a really steep learning curve and I think the following quote sums it up pretty well: "I use Vim for 20 years now. Because I do not know how to exit". Nevertheless, once you are aware of the most important keybindings, you get used to it and you will catch yourself trying to use them in programs, where they are actually not (yet) available. This is why I also installed a plugin for Vim keybindings in my Browser, called Vimium. Without any doubt you will recognize how your work flow changes in a positive direction if you are less determined by your mouse respectively trackpad! Trust me, I didn't want to believe it either!

At a certain point in my life as a nerd I also replaced the default floating window manager of my Linux operating system by a tiling window manager called Awesome WM, which provides a Lua interface and hence the opportunity of developing custom plugins. One of them enabled the usage of Vim key binding for switching between the windows on my desktop.

Anywhere you go, Vim will most probably be available, especially in an Unixoid environment. Being familiar with Vim in this context is in particular of advantage when it comes to editing files on remote, so you do not need to first download the file, adapt it locally and upload and replace the old version afterwards. Vim distributions like SPF13, SpaceVim and Janus ship with a whole bunch of preinstalled plugins, which makes you even more productive. But what happens if you want to install plugins in hindsight? YouCompleteMe and JediVim, just to mention two of them, are plugins that you need for efficient development with Vim but installing them and setting them up correctly is a real strangle. So you have to ask yourself: Do you really want to spend your time with a quite complicated installation of these plugins?

You might now ask "Well LHP80, telling us so much positive aspects of Vim, why do you even consider other editors?". That's pretty easy, let me explain why: Even though there are well known distributions, you might want to customize you editor to your needs. Hence sooner or later you will come to the point where you need to read and write Vimscript, which is Vim's own Turing complete scripting language. Let me quote a quite frustrated user from HackerNews on this topic, who will explain you why you really don't want to use VimL:

So right, I haven't tried writing anything serious in Vimscript, but the few times I tried it I was confused. At this point, it looks like someone took Lua, added a dash of Python, and then added "fixes" here and there because why the hell not. Like the fact that you can't put an array over multiple lines without adding a backslash (I guess?). The fact that you have not just == but ==? and ==#. Sure, there are reasons for this, but there shouldn't be. The fact that you can abbreviate everything, which sounds like a good idea, but sure makes code harder to read. The fact that there's no module system or anything, functions in the "standard library" are just there out in space (fortunately, they're named consistently and they have okay names). The fact that you have to scope functions because a capitalized function is Special. The fact that to call a function, you have to use call() because otherwise Vim interprets it as a command. (Unless it's scoped?) Oh, and Vim regexes don't conform to any standard you might be used to (except for \v, but I don't know that that conforms to).

Apart from its keybindings I always loved Vim for being fast. I mean really fast. But the more plugins you add to Vim to make it more usable, the slower you get and after a certain amount of plugins you are going to wait a couple of seconds until it actually opens. As a side note: This is the exact same reason why I quitted the Atom editor.

The last aspect that scratches my mind about Vim is related to sessions. I am totally aware of the fact that vanilla Vim is supposed to be used as an editor for quick and fast changes. Using various plugins we try to give it the flavor of a real IDE, but now imagine you are working on a coding session for a couple of hours, with multiple buffers, tabs and splits. Don't you want to save that session for later use? Indeed, there are plugins for this, but they do not really meet my requirements of a 1:1 session restoration.

All in all I still really like the look and feel of Vim and I always will have an eye on its development. Hopefully the NeoVim project will manage to improve the extensibility and maintainability of Vim in an adequate way and hopefully they will come up with an easier way of plugin maintenance. Furthermore I really would like to see a way of easily(!) exporting your current setup of Vim, with all its plugins and custom add-ins. And for all the readers who think: "Why doesn't he simply copy the dot-files?". The answer is: Because it usually breaks and needs further configuration, especially if you have a done a lot of customizations to your personal Vim.

Emacs

Emacs vs. Vim is like David vs. Goliath or Tabs vs. Spaces. A never ending question depending on the matter of taste. Some people like the Emacs keybindings more than the Vim bindings, or vice versa. Nevertheless, from my personal experience the aspect I personally like most about Emacs, is its way it manages packages. From a technical point of view it is well implemented and reliable. Quite contrary to how Vim realizes package management.

Emacs likewise comes with an own language that provides an interface for customization, but in contrast to Vim, the Emacs' configuration language is based on Lisp and hence functional as well as very readable, see the following Wiki article for details on Emacs Lisp.

Anyhow, as a Vim guy that furthermore prefers spaces over tabs, I missed my Vim keybindings. So I did some research on how to get them back and I ran into Evil. Yes, you have read correctly, I said that I ran into Evil.

Evil stands for "Extensible vi layer for Emacs". It provides Vim features like Visual selection and text objects, and provides you the most Vim like experience within Emacs. In this context I definitely refer to the following YouTube video, which describes the scenario of switching from Vim to Emacs.

You might ask now: "Emacs might seem to solve all the issues you had with Vim, so why the heck do you not stay with Emacs?!". The answer is quite simple. Because it took a very long time to get used to the default Vim and additionally my custom keybindings and I am really not in the mood to re-adapt to anything besides Evil, which of course does not cover all functionalities of Emacs. Nevertheless, IMHO Emacs combined with the Evil layer provides the best of two worlds and for anyone who does not want to configure it him or herself could make use of ready-to-use distributions that ship Evil out of the box, see for example Spacemacs.

Sublime Text

Sublime Text actually was one of the first real code editors I used. It's written in C++ and Python and extremely fast and responsive. Using Python as the programming language of choice for their API makes plugin development comparably easy. A C++ powered backend enables Sublime Text to open almost immediately and perform very quick searches. In contrast to Sublime Text, Microsoft's counterpart Visual Studio Code depends on Electron, which is a framework for bundling an instance of Chromium and your code written, in JavaScript respectively Node.js. On the one hand it makes VS Code very extendable, but on the other hand using an entire instance of Chromium for a text editor makes the app start up slower and it makes it to use more memory. Hence Sublime Text has a remarkably lower memory footprint than VS Code.

Sublime Text furthermore support the Vim keybindings out of the box and it does that even more accurate than VS Code, which is definitely a plus for every Vim enthusiast like me.

Microsoft Visual Studio Code

Microsoft's Visual Studio Code is a source code editor developed by Microsoft and runs on Windows, Linux and Mac OS. To be honest, as I mentioned before, it pretty much reminds me of Microsoft's counterpart to Sublime Text, with the difference that VS Code is free and open source.

It comes with a well organized and rich marketplace and tons of plugins which makes it highly extensible and customizable. Comparable to Emacs' Evil plugin, there are likewise layers for VS Code, for emulating the Vim keybindings.

Using Electron, VS Code combines web technologies such as JavaScript and Node.js with the flexibility of native apps, which makes it a remarkable editor. All in all IMHO VS Code and Sublime Text are quite comparable with the main differences of Sublime Text having a faster backend but VS Code in contrast being free and open source.

Final Words

As I mentioned at the very beginning of my post, I am totally in love with Vim and the Vim keybindings. Nevertheless, Vim's scripting language as well as its package management more and more forced me in direction of Sublime Text and MS Visual Studio Code. Although these two code editors are quite comparable, Sublime Text's C++ powered backend and its native support for the Vim keybindings make it my current editor of choice.