Searching for the perfect editor

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, SubEthaEditBBEdit/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. 🙂

This entry was posted in Tools and tagged , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

4 Comments

  1. Posted August 18, 2011 at 2:30 pm | Permalink

    Great post Eliot!

    I would say, though, that under your Rubic Table that Emacs should be listed as highly assistive. Out of the box, the first page that loads is an introduction that links off to the Emacs tutorial and a guided tour - that will have you mastering the basics in no time.

    In addition you quickly learn things like M-x aprops [string] to do a search of all commands for a word if you can't remember a command. M-x describe-key [key command] if you want to know what a certain key command you are running is actually doing. As well as a ton of others helpful introspective commands.

    I just realized something recently about the Vim / Emacs debate (that will undoubtedly go on until the end of time.) I've been an Emacs user for a few years now and through every job, no matter what back or front-end languages involved, what compiling processes are required, whether it's on remote or local dev machines, whether it's on Unix or Mac machines - I have been incredibly efficient with Emacs. The thing is, I always here "Vim can do that" from Vim users, but when I it finally gets down to "Do you use it at work?", on more than one occasion I have gotten this answer: "Oh, no, I use [Eclipse / intellij / other massive GUI editor]."

  2. eliot
    Posted August 18, 2011 at 2:35 pm | Permalink

    Thanks for your input, I'm interested to see what Emacs users think.

    However, I had something very specific in mind for my criteria of being "assistive," that "a code editor should provide facilities for code completion and inline display of documentation relevant to the code being written." What I meant is intellisense-style code completion and display of inline documentation for YOUR code and classes. I.e. if I define a class "Foo" with some instance method "bar", when I type
    foo = new Foo();
    foo.

    and hit the completion key, "bar" should come up as an option. Also, if I have defined documentation for my instance method, i.e. what it does and an explanation of what the arguments are, those should also be easy for me to view inline as I am editing, by some sort of pop-up tooltip or something like that. This is a feature provided by most modern IDEs, but only for a small subset of supported languages.

    My understanding is that, at least for the completion bit, this functionality is achievable in Vim through reading a tags file generated by running exuberant ctags against my own codebase periodically. Correct me if I'm wrong, but I think that Emacs also requires exuberant ctags to be set up to provide that level of completion for a variety of popular languages such as PHP, Java, etc. I should also revise my definition to include jumping to declarations and definitions of symbols, another IDE feature I miss sorely when using pure Vim sans ctags.

    In this case I'm actually arguing against the "Vim can do it" argument - Vim *can* be assistive by my definition, but it's so much of a pain that nobody I know, including myself, has ever bothered to set it up and use it at work. I've recently been using a mix between Vim running on our dev box, and the jVi plugin in NetBeans to do my editing, which supports 99% of the Vim commands I use as well as NetBeans's built-in assistive features for PHP and Java. However this setup would be useless for a language not supported by NetBeans. I also kind of hate NetBeans, it's a memory hog and periodically hangs.

  3. eliot
    Posted August 18, 2011 at 3:33 pm | Permalink

    I did a bit of Googling to check my claim about Emacs completion features, etc. Let me know if you can make heads or tails of this wiki page or this guy's notes on various tag solutions.

    If there actually is a good and easy way to get the sort of assistive features I described above working in Emacs for a relevant slice of popular languages, in a practical "do you use it at work" way please let me know and I will check it out. I based my claim partially off of reading stuff on blogs and also asking Emacs users I know if they use assistive features I described 'at work,' the answer I got was no. I guess I can always give viper-mode/Vimpulse a shot. 🙂

  4. Posted January 5, 2013 at 6:22 am | Permalink

    I have an Emacs starter kit (of sorts) and I'd love to see how you go with it if you try it out. In a nutshell I've tried to bring it up to scratch as a modern editing environment, so it has things like CUA (Ctrl-x,c,v cut/copy/paste) (Ctrl-z undo) as basic helpers for transitioning from TextMate and everything else that isn't Vim or Emacs.

    In addition there are assistive features, an extensive set of YaSnippets for several languages, and a newish library called AutoComplete, which offers dropdown completion similar to that found in modern IDE's. Now, don't get carried away, an ide specifically tailored to a language is going to have the best auto-completion available, but AutoComplete is a very good addition to Emacs.

    As well as that, the usual autocomplete/abbreviation expansion stuff in Emacs is bound to Alt-/ and Super -/ (Cmd on mac, needs to be mapped on other platforms.) This will autocomplete filenames and any string in an open buffer, as well as any known words for the current editing mode.

    Anyway, what my starter kit most notably does, is not shove Emacs down your throat, and tries to make it as accessible as possible, (if you want to unbind cursors, you can do that yourself, but I'd suggest learning to navigate with C-s C-r instead, if you really want to improve your editing speeds.)

    Other starter kits want to admonish you for not already being an Emacs devotee... which to me is the most wrong headed approach. Mine on the other hand is meant to show you it can stomp any other general textediting software, with it's eyes closed.

    Give it a try.

    https://github.com/ocodo/emacs.d

    (Note: has a fair bit of Os X specificity and is designed to work with Emacs24.)

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*
*