An Epic Tale of Comparison in The Text Editor Wars

The programming community is filled with intellectuals who don’t fight for decades about silly things, right?

WRONG!

Programmers fight about the silliest things I can imagine. We are talking about “my Pokemon is better than yours” type of shit here.

In order to understand The Text Editor Wars, we must time-travel into the past, to a place where computers were the size of buildings, network security was unthought of, and … ah, you get the idea.

A long time ago there were two leading text editors:

• vi (and its children, the most famous of which is Vim)
• Emacs

Legends talk about megabyte-long flame wars. Can you imagine? Honestly, I can’t (it was way before my time, but still).

Point is, this isn’t a new trend. People have been fighting for their text editor since the dawn of time computers.

For a historical overview of this infamous war, have a look at this Wikipedia article. What happened (in layman terms), is some guys started arguing over email about which text editor is better. Naturally, more guys joined in because us IT nerds have nothing better to do really, and before long the email thread was several hundred emails long. After that, the same argument started popping up in forums, with literally hundreds of comments per thread defending either vi or Emacs. When the forums started dying out and personal blogs became more popular, it was trendy to make a long post defending your editor of choice and talking trash about the competition.

Nowadays, there aren’t so many internet flame wars (regarding text editors, that is). However, if you search Youtube or Google, you will get a lot of videos where guys have entire conference panels where they defend their editor. There are also meet groups for some of the editors.

Don’t get me wrong—to a software developer the text editor is very important, as you spend a large chunk of your day in it. Having a text editor that fits your working style will make you much more productive—although it’s kind of silly for grown men and women to fight about such things, don’t you think ? What’s gonna happen next, people fighting about sports teams ? Oh wait…

So, let’s end this war today by finding the greatest editor of them all.

Before we continue, I want to make a few disclaimers:

• I am a Vim user (just like a vegan, I have to say it).
• For this post I will consider Integrated Development Environments (IDE) to be text editors (since IDE is basically a text editor with some more advanced features like generating boilerplate project code).

Also, we need to be on the same page regarding text editors (in general), so let’s look at some basic parameters for them and how they function.

What Should We Expect from A Text Editor?

What is the bare minimum to expect from a text editor?

1. 1. It should be reliable, saving when we say it should save, flushing our latest changes to the disk during a system crash, etc.
   2. It should have syntax highlighting because, honestly, who bothers reading what they are writing?
   3. It should be able to show the line numbers, regardless of if this feature is used or not.
   4. It should enable the user to edit text quickly. I am talking about hotkeys like “go to line n” or “delete the next paragraph.” Having these sort of things available makes you work more efficiently.
   5. It should allow search and replace (maybe with patterns). In most Graphical User Interface (GUI) editors it is triggered with ctrl+f. This shortcut helps a lot when you have to rename a variable/function/anything really.
   6. It should possess tabs, so you can edit more than one file (think browser tabs).

Every modern editor has these features, although they should be the absolute minimum. If you manage to find an editor which doesn’t have these features (which is pretty hard, but still), this is a huge red flag and most likely you should not use this editor. Examples of good text editors which have the above features by default are Vim, Emacs, Atom, and Sublime Text.

I also recommend that the text editor should have some of my favorite, more advanced  features:

• Project tree, which basically shows the directories and files from your project root.
• Autocomplete. There are a lot of debates as to whether autocomplete is good or not. The pro guys say that it saves time and protects from mistakes, and the con guys say that you should know the code base in which you work. Both arguments are valid, but I would still take less mistakes any day of the week.
• ctags is a utility which will generate an index file for your source code. In other words, it creates a file with meta information about your project’s code. For example, it looks for where a function is defined, or where it is called (ctags doesn’t do an index for where it is called, although some alternatives do), where the global variables are defined, and used, and so on. Ctags allows you to navigate lightning-fast through the code and can lift the burden of having to remember all of the code’s details. Most good editors (for example, Vim, Emacs, Atom, and Sublime Text) have built-in support for ctags.
• File map essentially gives you a scrollbar which is a minified version of your file. It looks cute and gives you an easy overview for large files. I don’t like it, but I can see why it appeals to many people.

Finally, let’s have a look at some of the IDE features. They aren’t limited only to IDEs, however most IDEs have them enabled by default and you need to install plugins if you want to use them in most text editors. Generally this is considered as an advantage that IDEs have over text editors.

IDE features include:

• Running the code inside an emulated console. It’s pretty useful, and usually quicker if you have only one monitor.
• Compiling the code as you go. It’s done automatically and shows your compilation errors in the text editor. I don’t really like this feature since it can get annoying as hell, especially when you get compilation errors while you are typing.
• Containing project templates that remove the boilerplate as much as possible.

How Should I Choose My Editor ?

If a lot of modern text editors have similar (or the same) features, does it matter which one I choose ?

Well, of course it does, but you can be productive with almost any editor. The question is, which editor is the right fit for you? It’s the small differences that matter. For example, most text editors have autocomplete, however since it’s implemented in different ways, the speed and intelligence varies. It matters what you prefer: in the case of autocomplete, whether you prefer to wait a bit more but get better suggestions, or to get lightning fast responses at the cost of fewer (and less on the point) results.

The rule of thumb is “learn one editor well”, and this is said for a very good reason. If you use several editors you will be master of none, and since a big part of your day is spent inside a text editor, learning how to use one above all others is optimal. In other words, if you don’t control your editor well, you are wasting your time.

Let’s assume you are looking for a new text editor. These are the steps you should take:

1. Think about what features you want, such as how you want your plugins, if a
   ny, installed (every editor has his or her own weird way of doing it; some even have several).
2. Install all editors you are considering and do some writing with them, without installing any plugins. The idea is to get a general feel for the editor.
3. Install the plugins you want and test out every editor. You want to spend several hours typing in each one. If you spend too little time, you won’t be able to get a good understanding of how the editor works for you.
4. Compare and decide. I usually have a Google spreadsheet which contains my results. Aside from functional features (eg. autocomplete, relative line numbers, etc.), I usually track things like load time and how the editor handles large files (e.g. 100mb worth of text). Once I have the info in an easy-to-process format, I cut down the considered editors by half. Then I repeat steps 3 and 4 until only one editor is left.

Which Text Editor Do I Fight for in This War?

Don't get me wrong—as a Vim user, I truly think that it is way better than Emacs.

In fact, everyone using Emacs can do us all a favor if they just stop doing IT and run away into the nearest desert, without any water!

All fanning of the flame wars aside, why do I choose Vim?

Since it has several modes (command/edit), all commands are very short, either one or two keys. Therefore, chaining commands is natural and effortless. I use ctags and window splits in my setup to quickly navigate and change the code.

I strongly dislike using the text editor to do the building, compiling, and testing of the software. I prefer to keep things decoupled and modular. If I am using a tool, I must understand it; I don’t want someone doing things behind the scenes for me.

I don’t use any plugins since Vim doesn’t lack anything a plugin could offer me. (Don’t get me wrong; there are tons of marvelous plugins out there that can do pretty much anything, but they usually don’t fit my workflow.)

In contrast, Emacs requires quite long combinations, and it truly shines through its plugins.

Emacs is a powerhouse, but for me Vim is faster, more comfortable, and doesn’t need plugins to bring out the best of it.

I want to give a shout out to Github’s Atom editor, which served me amazingly well. Its plugin management is amazing (everything is one to two clicks away), the autocomplete works beautifully, and the community which develops the editor is friendly and always willing to change. The deal breaker for me was that it took too long to load—think 40-50 seconds on startup. If you are into Graphical User Interface (GUI) editors I highly recommend you try it out.

Are The Text Editor Wars Worth the Battle?

I mean, seriously?

Meet groups for Vim users and panels at conferences explaining how you can listen to music from Emacs? Seriously? Come on, guys! Is this what we should invest our time in?

As much as I love my Vim editor, there are so many things to discover, build, and try out—are we really going to take up valuable time with this sort of fight? I’m not saying there shouldn’t be discussions about text editors, but there are way better things we can invest our time in, a sentiment I wish more people would adopt.

In my home town, for instance, there is this company which is a known user of a certain text editor. A buddy of mine went to an interview and they asked him what editor he uses. When his editor of choice wasn’t what they use, apparently they made some asshat comments.

That’s the level we are at: your text editor can be a question in a job interview.

Why are there so many fanatics? I don’t know.

Your text editor is just a tool.

Wielding it well will save you some time, but it doesn’t really matter for your end result. There isn’t an editor in existence that can give me the knowledge to build a better Linux kernel.

From now on, let’s try to not get carried away by silly things or put simple tools on pedestals, and instead focus on what’s important: catching all the Pokemon becoming better at what we do!

Your choice of text editor probably won't make much of a difference in your career but here's something that will: marketing yourself. I created a course just on this to help developers get the progress their careers deserve. Check it out here.