Saturday, June 28, 2014

Why I can't stop using Vim

In 1992 or 1993, my brother-in-law hired me to help him with some maintenance on a software system he had written for a customer. It ran on SCO Xenix.

"Hey, Bro, why doesn't 'EDIT' work on this computer?" I was a DOS rookie back in those early days, having just started my major in Computer Science.

"Um, there's no EDIT command on Xenix. Let me introduce you to vi. You use hjkl to move around, plus a few other keystrokes. Once you get used to it, it's not that bad." I swear he had a sly grin on his face as he said that, but he was serious. Vi was what I was going to have to use. Only now, as I write this, do I recall that he was, at that time, working in Windows with a shiny graphical editor. Oh, well, he was the boss, after all.

Anyway, I learned to move around pretty quickly, hitting 'i' to start typing, and 'Esc' to move around again. I wouldn't say I was a wizard, but I got the work done. We would tap away on Wednesday nights and Saturday mornings in our work sessions, while our wives played Super Mario Brothers out in the front room. Good times. I really miss it sometimes.

That was the side job. The day job kept me programming on OS/2 and some Windows. The stock editor on OS/2 was a decent editor - you typed text, and it saved it just fine. I cranked out many, many lines of code using that editor.

We're programmers. Editing text is the very essence of what we do. We get excited about these sorts of things.

Fast forward to 1997. My brother-in-law once again helped me get my foot in the door at a small telecommunications company in Phoenix. My first workstation was a Sun SPARCstation 20, running Solaris. Cool, I thought, I can use vi to get going. But by now, everyone was using UltraEdit on their Windows machines. I didn't have one of those, but I really needed the productivity boost of a better editor. A little Yahoo searching turned up some vi clone called Vim. There was a new release of it, version 5, and it came with syntax highlighting! Take that, UltraEdit!

This is getting long... Let's just say, I used Vim for all my editing on that SPARC station. And when I finally got a Windows PC, I was elated to find that there was a Windows version of Vim, with a GUI and everything!

Vim and I have had a bit of a fickle relationship over the years. Although it does an amazing job helping you type text, it's not flashy, and it's not perfect, and because of those imperfections, I strayed from time to time, looking for something to fix those imperfections, and still give me the second-nature editing reflexes I had come to enjoy from Vim.

Here's a list of the things that have caused me to look beyond Vim.
  • viml - Vim's built in scripting language is tedious to work in. Some folks have done some amazing things with it, but, try as I have, I can't get myself to enjoy it.
  • Glossy finish - I admit, I'm guilty of a little editor envy when I see some of the prettier interfaces out there, especially these days.
  • Emacs's Org Mode - this is such a killer emacs app. Others have tried to replicate it for Vim. Someday.
  • Context-aware code completion - OmniComplete provides a decent framework, but nobody has really matched the power of Visual Studio, Eclipse, or Xcode.

Yes, I have strayed, and flirted with many other editors...

  • JEdit (Ugh, looks like a Java Swing App, and too much clutter everywhere)
  • Emacs (Love the features and the eLISP, but can't tolerate the myriad key chords needed to navigate around my files.)
  • Emacs + Evil Mode (Evil mode is REALLY good. The only thing that made me frown was poor code navigation via ETAGS.)
  • J (A tiny little Java based editor, built around ABCLisp from Armed Bear. I really loved this editor, but it fell behind in features, and I needed more power.) EDIT: This editor is still alive (somewhat) on github: Thanks to bokchoi on for the link.
  • Programmers Notepad (Decent editor, but not enough features).
  • Editra (a Python/WxWindows based editor, with Vi emulation. But it also lacked things like smart indent and other features I have come to take for granted.)
  • Notepad++ (A very respectable editor. Tons of features. But for some reason, I just don't enjoy using it. Maybe it's all the visual clutter around the borders of the screen?)
  • Visual SlickEdit (I actually bought a license for this once, about a decade ago. I liked using it, but I could only afford one platform, and there are lots of free editors that do most of the same things. With Vim in my toolbox, I'll never pay $300 to edit text.)
  • TextMate (When on a Mac, it had to be tried. The free TextMate 2 is a great editor, and I flirted with this one the longest. Were it not for the things I'm about to mention below, I'd be using this editor as much as possible.)
  • A whole slew of respected MacOS based editors: Kod, Smultron, SublimeText, TextWrangler, etc.

Here's where they all fell short, and what took me back to Vim every time...
  • hjkl for navigation
  • / for searching (really, no other editor has made it this simple)
  • m to bookmark a spot, ' to hop back to it
  • and ctags
  • q to record a macro; @ to execute it again
  • 1G to go to the top of the file, G to go to the bottom
  • ^, $ to go to the front, or end, of a line.
  • Text Objects! Holy cow, if you're a Vim user and you're not using these, you're missing something special.
  • Platform ubiquity. (Mac, Linux, Windows - Vim works great on all the platforms I use day in and day out.)

What it boils down to, really, is that the above keys have become a part of me. They are so ingrained in my brain and reflexes, that I think of what I want done in the text and my hands just naturally do it for me. It's like drinking water. I don't have to think about how to go about bringing the cup to my mouth and tipping it just right. I just do it, and keep going on about my business.

THAT's what keeps me coming back to vim.

Yes, it still has its imperfections. I end up using IDE's for a large part of the work I do, and they provide a lot of what I wish vim would do better. But there are some plugins that bring the above features into those environments...

For Eclipse, I use the Vrapper plugin. Works great!

For Xcode, I have used XVim. It's not perfect, and crashes Xcode in a couple of situations. But it's getting better, and is actively developed.

As a special bonus for having read my lengthy article all the way to the bottom. Here's a chunk of my .vimrc that allows me to have nested "project" settings in my directory tree...
" Search for any .vimsettings files in the path to the file.
" Source them if you find them.
function! ApplyLocalSettings(dirname)
    " Don't try to walk a remote directory tree -- takes too long, too many
    " what if's
    let l:netrwProtocol = strpart(a:dirname, 0, stridx(a:dirname, "://"))
    if l:netrwProtocol != ""

    " Convert windows paths to unix style (they still work)
    let l:curDir = substitute(a:dirname, "", "/", "g")
    let l:parentDir = strpart(l:curDir, 0, strridx(l:curDir, "/"))
    if isdirectory(l:parentDir)
        call ApplyLocalSettings(l:parentDir)

    " Now walk back up the path and source .vimsettings as you find them. This
    " way child directories can 'inherit' from their parents
    let l:settingsFile = a:dirname . "/.vimsettings"
    if filereadable(l:settingsFile)
        exec ":source " . l:settingsFile
autocmd! BufEnter * call ApplyLocalSettings(expand("<afile>:p:h"))

I posted it to Reddit a couple of years ago, and the feedback was overall positive. There were a few good ideas posted in the comments, so here's the link.

Thanks for reading. I'd love to hear your feedback below.

EDIT: spelling corrections; added links to other editors


  1. "Context-aware code completion – OmniComplete provides a decent framework, but nobody has really matched the power of Visual Studio, Eclipse, or Xcode."
    Have u tried Eclim? it works more then perfect for me. (Eclim is a headless eclipse server, with which u can interact through vim)

  2. For going to first line "gg" is speedy than "1G".

    Thanks for the article.

    Bye, I must search what Text objects are.

  3. You might prefer "gg" to "1G". It does the same thing and is quicker.

  4. Just in case: gg will get you to the top of your buffer more easily than 1G

  5. Well written but opinionated article. But the reason I post is because of the Vim key mapping plugin which I occasionally engage in IntelliJ IDEA studio. This might interest you and I noticed it wasn't on your list. Although its hard to unbloat the software (boot time of the program and indexing can be slow unless you have a SSD,) I've come to enjoy the versatility and modernity of this particular IDE.

  6. I've heard great things about IntelliJ, but I have never used it. Thanks for mentioning it so others can look into it. Here's a link for anyone who's interested.

  7. I'm going to have to re-train my brain to hit gg instead. Thanks to Christopher, Sean, and bibliotranstornado for point this out. Definitely faster than the 1-<shift>-g I've been using for 20+ years!

    Funny story - that brother-in-law tried to teach me that the easiest way to get to the end of a line of text was to type 1234l. I'm glad I quickly realized there were better ways. :)

  8. I tried getting Eclim to work several years ago and never got it right. I know a few people like yourself that love it. I may have to give it another shot.

  9. I am also a vim enthusiast and can relate to what you said here. I even made a list of Vim emulators on other platforms/editors.

  10. Clang complete.
    C-x C-u
    or just foo-> and the list of possible completions pops up. And it's a proper list populated by clang (or clang++) parsing your code and knowing what's legal rather than just guessing. Jumps to definitions without having to create a tags file too.

  11. Thanks for sharing your story. Just want to say that I nodded all way true, feeling very familiar to what you say.

    I think it boils down to the fact that once you have a two-mode editor engraved in your fingers and brain, it is impossible to feel at home elsewhere. I switched to vi(m) in -96 (leaving emacs), and have at times tried the new glossy editors. But it is impossible to switch back to single-mode.

    And which other editor have something like cib - try that next time you need to replace some text inside parenthesis:)

  12. Thanks for mentioning it. I should have mentioned it in the main article. I have used clang-complete and love it. I work in something of a polyglot environment, where C/C++/ObjC are only used occasionally, and the client project I have worked on since finding clang-complete is a complete mess to set up (literally hundreds of -I includes and -D defines).

  13. I am really enjoying IdeaVim plugin for IntelliJ IDEA - using it with PyCharm for Python development. There're couple of imperfections that don't really get in the way, but other than that my productivity is very high due to having both powerful IDE and Vim combined.

  14. Awesome post. As a vim enthusiast too, I love it when others get around to sharing why they used vim. But your article here says more. It shows that it's important not to get married to your editor, and only from the experience of trying other editors do you a) have the right to share the pros and cons of vim and b) appreciate how powerful vim can be.

    Also, Vim Awesome is a great little repo for searching for plugins!

  15. I've learned to never actually delete Vim when I go exploring another editor. I just know that I'll be back someday. I have always come back, and been happy to do so each time.

    But, oh, how I wish I had an Org-Mode equivalent for Vim, today!

  16. Thanks for the link. There is lots of good info there!

  17. Take a look at YouCompleteMe for awesome code-completion. Works well with clang-languages, plus others too.

  18. "We’re programmers. Editing text is the very essence of what we do."

    I'm a programmer. Writing and editing and debugging programs is the very essence of what I do. Editing lines of text is simply an implementation detail which describes how most programming has been for the past couple decades.

    When my father learned to program, programming consisted of flipping switches. When my first boss learned to program, programming consisted of punching Hollerith cards. When I first learned to program, programming consisted of entering hexadecimal opcodes. In hindsight, it's clear that none of these is the very essence of programming.

    I sincerely hope that we're not stuck forever with today's convention of writing programs out of raw ASCII text, with funny punctuation (the kind common on our keyboards by historical accident, but almost never used for actual text) and the occasional whitespace for style. Computing didn't get stuck on front-panel switches, Hollerith cards, or hexadecimal opcodes, convenient as each of these was in its day.

    My father is still suspicious of any computer that doesn't have lights and switches on the front panel for debugging, and I'm sure most of today's programmers will have trouble adapting to post-textual programming, too, but time moves on. Vim will eventually die out not because there's going to be a better text editor that will convert all the Vim users, but because text itself as a fundamental representation will die out. Vim will be a good solution to an obsolete problem, like the hand-crank on the front of the R1 which could step the processor forward 60 instructions at once.

  19. Great perspective. Thanks for contributing!

  20. I use Vim for the reasons you mentioned (text objects ftw), and one other, key mappings. I have my key mappings so engrained into my fingers that I end up with vim mappings in work done in other editors/word processors. Plus it's infinitely extensible so if I need it to do something it doesn't do stock, I can find a plugin.

  21. yes you should definetly give it another shot, you wont regret it once you seen the potential it has, and how perfectly it fits into vim.

  22. The context-aware completion is obviously really language dependent -- I have had fantastic results with Java, C++ and Go(lang). I have had "decent" results with both Python and Ruby -- but not nearly as perfect and impressive as the first 3 I mentioned.

  23. I'm an Emacs convert, who used Vim exclusively for a couple of years before switching. I think you really should give Emacs another try.

    Emacs is an (outstanding) Elisp IDE first and an editor later. This means that the plugin development is a default mode for using Emacs, not something you only do when you have to. This, along with package.el, means that you can make your Emacs into extremely powerful tool with less work than you'd need to do the same with Vim.

    The greatest strength of both Vim and Emacs is their configurability and extensibility. You're going to live half your life inside an editor, better make sure it suits you. I had about ~1k loc of vimrc when I used Vim for this reason. I disagreed with some of Vim opinions on how things should be done so I just remapped and scripted my way around those things.

    Now, I disagree with Emacs even more, for example default keyboard shortcuts - as you mention - suck and are mostly an accident of history. But with Elisp being so much better language than VimL, and with Emacs being such a great Elisp IDE (I can't list all the features which make it that great here, but the following two blew my mind when I switched: visual debugger for every single editor command and easy go-to every command definition, even if it's written in C) it took me only a few months to script the hell out of it and beat it into submission. I have ~5kloc of my own .emacs.d code and almost every line there was a pleasure to write. I can't say the same for vimrc.

    Emacs *is not* an end-user editor, in my opinion. It's not a ready made product. You may try one of community provided starter packs, like Prelude, Stackemacs and so on if you want such an experience. But if you're a Vim user, I think sooner or later you will want to customize things, and that's where Emacs beats every other editor in existence right now. For me Emacs is a framework and a toolbox for building editors and if you want to have control over your experience, you're better off with such a framework than a ready-made application.

    In the future, I believe, Emacs will be killed by LightTable, which has everything Emacs has but packaged with a modern technology. However, this will only happen when all the important plugins are ported to LT, which will take time. It took Emacs 30 years to develop them all in the first place.

    I won't write about downsides, which are many. Emacs is old and crufty, develops slowly, has 30 years of accreted quirks and so on. But there are downsides to everything and I believe that right now Emacs presents the best balance of good and bad features.

  24. Thanks for contributing your thoughts. I enjoy well thought out ideas, and it seems you have thought a little more deeply about how/why you use a tool. I think for some, a text editor is merely a tool, and almost any editor will do. For others, a text editor is more like a friend, and being friends should be a mutually beneficial relationship, each helping the other do their job in better ways.

    And if that's the case, that Vim and I are friends, I'm probably not a great friend, since I'm always enticed away by better looking friends. Vim must be a very forgiving soul, because it's right there waiting for me each time I come back, and we pick up right where we left off. :)


I value comments as a way to contribute to the topic and I welcome others' opinions. Please keep comments civil and clean.