Why certain text editors make you more productive

Here is an uncomfortable truth: some text editors will make you more productive than others. You can argue this back and forward, but you know it is not a lie. It is quite possible to write all your code in notepad.exe but most people prefer not to do that. Why? Because there are better tools for the job: advanced programming editors, IDE’s and the like. Some tools are better than others at any given task.

Here is another uncomfortable truth: extensible text editors can be better at boosting productivity than ones that offer a lot of features out of the box, but no possibility of fine tuning the performance, save for maybe a rigid plugin architecture. Let me use Vim as an example here, because that’s what I know the best. When you start using Vim, you begin with a blank slate – a generic editor with key-stroke saving modal setup, built in macros and etc. It is quite powerful out of the box, but probably not overwhelmingly so. The built-in commands and features can only take you so far, and there are products out there that offer a programmer a more specific set of features right away. Case in point: big IDE’s like Eclipse and Visual Studio ship with inline debuggers and code inspection features and etc. Vim does not have that.

Vis just a text editor – an efficient machine for hacking away on blocks of text, but a limited one. That’s what it was designed for. The interesting part of Vim is that it is almost infinitely extensible. It has it’s own scripting language which allows you to almost completely change it’s behavior and redefine almost all the default settings. What is more important though, even though VimL is quite ugly (like Perl level ugly) and inconsistent as scripting languages go, it usually proves to be quite accessible to new users.

When you start your adventure with Vim, you usually go out and look for .vimrc tweaks – things you can add to your vim configuration file to make the editor more useful: like enabling syntax highlighting, line numbering, etc. In the process, you also learn how to rebind keys, capture user input, change default behavior and etc. Eventually you learn that you can put little functions in your .vimrc – stuff that can take some data, process it, spit it back to the buffer or whatever. And all of this is just basic configuration tweaks – stuff you put in your config file.

Eventually you experience an epiphany – you realize that the so called Vim “plug-ins” you have been installing and hording in addition to your config tweaks are not actually “plug-ins” at all. They are simply scripts written in VimL – the same language you have been using to hack your .vimrc all along. A language you already sort-of know by proxy. The side effect of spending many man-hours tweaking your editor results in you learning all the basic techniques used by the plugin designers – function calls, hooks, key bindings, executing normal mode commands, etc..

So what do you do? You start writing your own plugins. You start small – you take chunks out of your .vimrc and tinker with them. Here is a cool example from my setup:

" toggle between relative and absolute line numbers
function! g:ToggleNuMode()
	if(&rnu == 1)
		set nu
	else
		set rnu
	endif
endfunc

nnoremap  :call g:ToggleNuMode()

As you can see from the comment, this small bit of code lets me toggle between relative and absolute line numbers in my file. This is already quite unique feature to vim – most editors only offer absolute line numbers. But with Vim’s modal editing features, relative numbers are very useful (in vim you can preface various commands with numbers to affect multiple lines and etc..). This little bit of code is all I need to set up dynamic toggling between the two systems. Not only that but it actually shows how much of VimL you tend to learn just by tinkering. This bit illustrates:

1. Defining global scope functions
2. Testing vim’s built in option variables by accessing them with & symbol
3. Toggling built in option variables on and off
4. Calling functions in global scope
5. Binding a function call to a key stroke

Once you grok simple function calls like this, you are about five steps from hard core VimL programming. The next step after this, is realizing just how easy it is to code and test these things. For example, I could save the above function to some random file and issue the following command:

:source %

This interprets the file and will show you errors if there are any. Then it loads the file and it becomes part of Vim. For the remainder of the session you will be able to use the call command to call this brand new function as you edit it some more. It’s that easy. Once you are happy with the function and you want it to become permanent feature of your editor you simply do:

:sav ~/.vim/plugins/myfunction.vim

Boom! Now it’s a plugin. It’s that easy! Can you do that in Eclipse or any other plugin enabled IDE? In most of them, plugin development is much, much more complex than this. As far as I can tell only Vim and Emacs offer you this degree of flexibility. Getting into plugin development is almost inevitable side effect of increasing familiarity with these editors.

And since you will be making your own plugins anyway, eventually you will get to the point of generalizing and releasing them to the public. Here is a cool example: Steve Losh wrote an excellent blog post about his journey from TextMate to Vim in which he essentially went “boy, I wish there was some plugin that would let you browse Vim’s undo history”. Some time after publishing it, he amended that bit to let people know he got tired of waiting for that plugin and so he wrote his own. I must attest that his Gundo plugin is quite awesome.

Most Vim users eventually become VimL hackers simply by the process of day to day interaction with their editor of choice. Same thing happens to Emacs users which usually end up quite proficient at writing Elisp code mostly by accident. The beautiful side effect of this process is that it gives people power to tune their configuration to their very specific needs. Vim starts as a generic catch-all editor, but ends up being a finely tuned instrument specialized for the exact kind of work you do with it.

Vim and Emacs empower their users to do what programmers tend to do anyway: script and automate mundane things. Half the time our projects essentially revolve around automating and streamlining other people’s jobs. At the same time what we do – writing code – remains quite inefficient. And I’m not just talking about copying and pasting boilerplate code – most editors can handle that. Vim and Emacs let you script your editor directly and make it do exactly the things you want.

This does not usually happen in communities clustered around big IDE’s. Most users of Eclipse remain just that – users. While their IDE has a very powerful plugin API, the barrier to entry is usually pretty high. Grokking the infrastructure that drives the plugins is a non-trivial task in and off itself. Putting a plugin together is whole project that comes with hundreds of lines of Java boilerplate that need to be in there, just because that’s how Java works. This organic drift from casual user to power user, to expert hacker and plugin creator is rare. Only the most determined and motivated take that last step, whereas in Vim and Emacs communities it is a commonplace thing.

Which is not to say that IDE’s are bad, or that Vim is better. It’s just an extremely extensible tool that will evolve with you over time. The more you use it, the smarter and more efficient it becomes.

If you are interested in learning more about VimL, this is a great place to start.