Text editors. Yawn. Who cares? It's just text!

For many people, it really doesn't make a difference. But I'm a programmer. I edit code for a living. My editor is the tool of my trade and I want to use the most efficient tool available.

I'd be preaching to the choir if I was telling programmers that they should use good text editors. But I've noticed some patterns in the history of text editors I've used that have made me come up with my own philosophy about choosing an editor. My goals and usage habits are certainly not the same as everyone else's, but I hope that in sharing them I might get you to reflect on your own habits and see if they match up to your goals.

I have used many different text editors over the years, starting with the crappy built-in editor for BASICA. I've used Notepad, Metapad, Pico/Nano, TextEdit, SubEthaEdit, BBEdit/TextWrangler, Notepad++, Vim, Visual Studio, and NetBeans to name a few. My reasons for switching (or using more than one editor) were various. I was moving to a different OS, or using multiple OSes. I found an editor with a cooler feature set than my current one and I wanted to check it out. The editor was recommended to me by a friend or teacher. I was learning a new programming language that was highly IDE-centric (like C# and Java) and it made sense to adopt a respective IDE.

I noticed something making all of these jumps between editors. There's a friction that occurs when switching, a penalty. When I had been using my previous editor I was developing muscle memory from repeated use of certain keystrokes to perform a task. In my next editor I'd habitually hit whatever key I was using in my previous editor for find, find and replace, save, copy, etc. This annoyed me a bit as I had to spend a good amount of time re-training my reflexes to use different keys, to get back up to the speed and subconscious efficiency I had in my previous editor. I began realizing that it was counterproductive to my efficiency to keep switching editors every couple of years. It made sense to pick one editor as my main editor and stick to it so I could retain and build off my muscle memory, a valuable byproduct of using the same editor for a long time. Muscle memory is valuable because it allows our conscious mind to think of an action, but our reflexes to execute it instantly. It can only be acquired through repetitions of an action.

... This phenomenon is sometimes called "muscle memory", a phrase that tellingly gives credit to an organ other than the brain. The brain is really in charge, of course, but the term rings true because the actions seem to happen without conscious thought. This is the ultimate in efficiency, leaving the higher-functioning parts of the brain free to concentrate on the task, rather than on the operation of the tool required to complete the task.

-John Siracusa

Somewhere along the line, somebody suggested I check out Vim, an improved version of the Vi editor. I ran my own Linux server so I was slightly familiar with Vi, as is any Unix user (it has a way of popping up from time to time since it's the default editor.) I knew one command, how to quit it! I found this arcane, cryptic editor really off-putting and unnecessarily complicated. What was wrong with Nano for editing HTML pages on my server?

The guy eventually convinced me to try learning Vim using a program called vimtutor. I tried the tutorial. It still seemed arcane and cryptic, but as I worked through it more, I started seeing some crazy possibilities. Vim possesses a succinct and powerful syntax for editing text in a really unusual fashion. I saw the possibilites open up for navigating and manipulating text in powerful ways that had never even occurred to me before. I'll spare you the details, but it was an eye-opening experience. My text editor could be a more powerful tool for accomplishing useful work than I had ever thought was possible.

I'm not here to preach Vim and get you to switch to it, or start yet another holy war with the Emacs crowd. It seems to me that Emacs is a perfectly valid alternative to Vim - I just don't have the mental capacity to learn both editors at once.

But, I do recommend that you try out a powerful text editor - ANY powerful text editor! I think it's an experience that every programmer should at least try. The best contenders right now in my mind are Vim, Emacs, and TextMate.

There are a few reasons why I decided to commit to Vim as my editor of choice:

  • Vim is powerful. As I have increased my mastery over its complicated set of commands and modes, my efficiency in editing text has risen proportionally. This is great for me as a programmer - the less time it takes me to mechanically edit text, the more time I can spend thinking about and writing code.
  • Vim is flexible. Once you speak it's language, you can combine commands to create expressions that accomplish a very specific and complicated text editing tasks in a few keystrokes. Its interoperability with the shell is cool. For instance, it's very easy to use Vim as a lightweight pseudo-IDE for any language that has a command-line compiler or interpreter. It has support for plugins and new syntax rules, which allows the community to contribute rules for all sorts of uncommon languages. If you know a language, there are probably Vim syntax highlighting rules for it!
  • Vim is ubiquitous. It's open source, and available on Mac, Linux, and Windows (and many other OSes including BSD!) In fact, any Unix system I've ever used, including Debian 0.91 from 2002 included some form of a Vi editor.
  • Vim is lightweight. I think it typically weighs in at around 20 MB. Right now, MacVim is consuming 16.9 MB of memory on my computer and averages about 0-5% of my CPU. This is in contrast to a full-blown IDE like NetBeans, which is 154.8 MB in size, and can take up between 5-30% of my CPU when running and a whopping 329 MB of memory! NetBeans sometimes produces noticeable hangs on my machine.
  • Vim is deep. I've never encountered another program with the same amount of commands, modes, etc. This put me off at first, but I've learned over time that each feature is present for a reason, and in mastering a new feature, I unlock new levels of efficiency in using the tool. It's a slow burn - I'd expect that Vim has at least a 10-year, perhaps even a lifetime learning curve. (You can learn the basics of vanilla text editing in a few minutes - I'm talking about the learning curve to fully utilize the tool's powerful features.) I can't spend all my time learning Vim, I need to also focus on learning programming languages, new technologies, etc.

I have been using Vim as my primary editor for something like 6 years now, and I am still learning new features every day. I find the time I've put in to learning the editor is really starting to pay off. Recently, a coworker who was watching me edit some HTML remarked, "Whoa, I thought people only went that fast in movies!"

Here's what I find lacking in Vim:

  • The learning curve is at times ridiculously steep which can be discouraging. It often takes me months to get enough use out of a feature to remember that it exists, how to use it, and finally how to use it effectively. I think, however, that this is part of the price of having a highly powerful and advanced tool for any sort of craft.
  • The documentation is dense and in many places seems to assume you are familiar with other aspects of Vim. Considering how massive the feature list of this editor is, that's not always the case. Thankfully links are provided - but I don't always feel like learning an entire new subsystem just to get one feature working! Google is my friend here as it's often more clear to read somebody's blog post than the actual Vim manual.
  • The scripting language seems clunky. I have no desire to learn yet another hacky Unix scripting language - bash is enough for me! That's okay for now since the handful of Vim plugins I actually want have already been written by someone else. Also, Vim can be downloaded or compiled with support for additional scripting languages such as Python.
  • Vim supports code completion, which is cool, but it's a real pain in the ass to set up completion for your own code (i.e. getting a list of methods that I can call on an object of a certain class that I wrote, which is a nice feature that some IDEs provide.) I have yet to meet anyone in real life that has actually bothered to do this. It requires setting up a program called ctags (or exuberant ctags) and running that every time you want to update your completion rules, which analyzes your code and produces a 'tags' file. Emacs has this exact same issue by the way, it also uses ctags! This is one area where bulky IDE's actually provide enough of a service to warrant their rather poor behavior! However, there is a built-in feature called keyword completion that works without any special set-up and is able to complete words in the current file. This is very handy for referring to variable names, etc.

With all of this in mind, I'd like to put forward my current list of qualities that an ideal code editor should have:

  1. Powerful - A code editor should be able to manipulate text in powerful and context-sensitive ways.
  2. Assistive - A code editor should provide facilities for code completion and inline display of documentation relevant to the code being written.
  3. Multi-language - A code editor should not tie you to any particular programming language.
  4. Crossplatform - A code editor should not tie you to any particular operating system.
  5. Plugin architecture - A code editor should be easily extensible to work with new languages by its user base.
  6. Open source - A code editor should be easily extensible to work with new operating systems by its user base.

How do some editors I know of rank against this rubric?*

Powerful Assistive Multi-language Crossplatform Plugin architecture Open source
Vim Yes Sort of Yes Yes Yes Yes
Emacs Yes Sort of Yes Yes Yes Yes
NetBeans Sort of Yes No Yes Yes Yes
Visual Studio Sort of Yes No No Yes No
Xcode Sort of Yes No No Yes No
TextMate Yes Sort of Yes No Yes No
TextWrangler Sort of No Yes No No No
Notepad++ Sort of No Yes No Yes Yes

*This table is highly subjective. I tried to include some popular editors that I haven't personally used much like TextMate and Emacs and assess them by reading about them and talking to people who use them. See Wikipedia for a more exhaustive comparison of text editor features.

I was a bit hard on the IDE's listed here. To be fair, most of them support a handful of different languages. However, I don't think they meet the criteria of "should not tie you to any particular language" since a lot of their more useful features such as code completion would not be available in anything other than those languages even if you were to use them as a plain text editor.

There isn't an editor that actually meets all 6 of my criteria. Vim and Emacs come the closest, but the fact that most human beings don't actually have the patience to install and run ctags for code completion makes me rank them down in the "Assistive" category, whereas in the IDE's this is automatic and built-in. I also ranked the IDE's down for "Powerful" because the context-sensitive editing abilities in their default editors are tied to their particular languages, whereas these commands in Vim are generic and work in any language. Also, if you've used Vim, your definition of 'powerful editing' changes and you realize that what are typically considered powerful editing features are weak sauce. :) Emacs gets a pass since it has a metric assload of modes for a bunch of different languages.

Other editors such as TextMate seem appealing, but are not crossplatform or open-source. I am a generalist; I write games for Windows, backends for Linux, and utilities for Mac OS X, among other things. Mac is my primary platform at the moment, but I feel like it would be foolish for me to put all my eggs in one basket by tying myself to a text editor whose creators openly proclaim it will never be ported to any other system.

Another enticing option is the franken-editor... people have actually written plugins for various IDE's that allow a simulated Vi editing mode (jVi, ViEmu) or in one case, a real instance of Vim to run inside of the IDE. This actually winds up providing a great mix of editing power and assistive support from the IDE. It's a win for Vim ubiquity since I can re-use my exact same muscle memory for editing within multiple IDEs. However, this scenario is plagued by the same issues that make the IDE fall short of perfect, by tying you to specific languages supported by the base IDE.

To wrap up, I don't think the ideal code editor exists. If you have the good fortune to be coding in a language supported by a decent IDE, that could be the ideal editor for that language, but not others, and you'll pay a friction penalty switching between the IDE editor and whatever other editor you use, unless you're doubly fortunate and there's some sort of plugin to make the IDE work like your other editor or vice versa.

Vim and Emacs are pretty dang good, but fall short of perfect in my eyes since it's such a pain in the ass to set up ctags. If either the Vim or Emacs community was able and willing to bundle this functionality up in a more automatic and integrated way (i.e. not making me compile the damn thing for OSX or force me to ask my sysadmin to install the exuberant ctags RPM in a shared environment,) they just might fit my criteria for perfect code editor. At least until I actually used them and thought up more features I'd want. :)