Computing stuff tied to the physical world

Learning vim

In Software on Jan 28, 2013 at 00:01

This post won’t be for everyone. In fact, it may well sound like an utterly ridiculous idea…

After yesterday’s post, it occurred to me that maybe some readers will be interested in what these so-called “programmer’s editors” such as vim and emacs are all about.

When developing software, you need a tool to edit text. Not just enter it, nor even correct it, but really edit it. Now perhaps one day we’ll all laugh about this concept of having a bunch of lines with characters on a screen, and working with tools to arrange those characters in files in a very very specific way. But for the past decades up to this very day, that’s how software development happens. Don’t blame me, I’m just stating a fact.

I can think of a couple of tools to use for editing text:

  • a non-programmer’s text editor or word processor (NotePad? TextEdit? Word?)
  • GUI-based programmer’s editors (UltraEdit, BBEdit, gedit, TextMate, Sublime Text)
  • an Integrated Development Environment, such as Visual Studio, Eclipse, Komodo
  • command-based programmer’s editor – the main ones are really only Vim and Emacs

Everything but the last option is GUI based, and while all of those tools have lots and lots of “keyboard shortcuts”, these are usually added for the “power users”, with the main idea being that everything should be reachable via clicking on menu’s, buttons, and text. Mouse-based, in other words.

There’s nothing wrong with using the mouse. But when it comes to text, the fact is that you’re going to end up using the keyboard anyway. Having to switch between the two is awkward. The other drawback of using a mouse for these tasks, is that menu’s can only give a certain amount of choice – for the full breadth and depth of a command-based interface, you’re going to have to navigate through a fairly large set of clever visual representations on the screen. Navigation means “pointing” in this case. And pointing requires eye-hand coordination.

As I said yesterday, I’m going back to keyboard-only. Within reason, that is. Switching windows and apps can be done through the keyboard, and so can many tasks – even in a web browser. But not all. The trick is to find a balanced work flow that works well… in the long run. Which is – almost by definition – a matter of personal preference.

Anyway. Let’s say you want to find out more about vim…

In a nutshell:

  • you type commands at it: simple keys, control keys, short sequences of keys
  • each of them mean something, and you have to know them to be able to use them
  • luckily, a small subset of commands is all it takes for simple (albeit tedious) editing
  • it does a lot more than edit a file: jump around, see multiple files, start compiles, …
  • but also: integrate with syntax check, file search, symbol lookup, batch operations
  • it’s all about monospaced text files, and it scales to huge files without problems
  • vim (like emacs) is a world in itself, offering hundreds (thousands!) of commands
  • bonus: a stripped version of vim (or vi) is present on even the tiniest Linux systems

In vim, you’re either in insert mode (typing text), or in visual mode, or in shell-like command mode. Typing the same key means different things in each of these modes!

Make no mistake: vim is huge. Here’s the built-in help for just the CTRL+W command:

Screen Shot 2013-01-26 at 23.58.29

Yeah, vim also supports all sorts of color-scheme fiddling. But here’s the good news:

  • you only need to remember how to enter insert mode (“i” or “a”), how to exit it (ESC), how to enter command mode (“:”), how to save (“:w”+CR), and how to quit (“:q”+CR) – and most importantly: how to get to the help section (“:help”+CR).
  • a dozen or so letter combinations will get you a long way: just read up on what the letters “a” to “z” do in visual mode, and you’ll be editing for real in no time
  • there is logic in the way these commands are set up and named, there really is – even a few minutes spent on vim’s extensive built-in introductory help texts are worth it
  • some advanced features are awesome: such as being able to undo any change even after quits / relaunches, and saving complete session state per project (“:mks”)

If you try this for a few days (and fight that recurring strong urge to go back to the editor you’re so familiar with), you’ll notice that some things start to automate. That’s your spine taking over. This is what it’s really all about: delegating the control of the editor to a part of you which doesn’t need your attention.

When was the last time you had to think about how to get into your car? Or how to drive?

Probably the best advice I ever got from someone about learning vim: if you find yourself doing something over and over again and it feels tedious, then vim will have some useful commands to simplify those tasks. And that is the time to find them and try them out!

Vim (and emacs) is not about good looks. Or clever tricks. It’s about delegation.

  1. On the Mac, you can even have emacs behave more like an OSX application with windows, etc. if you like by using Since I’m a dinosaur, and have been banging away at emacs since 1979 or so, I also will use gdb-mode inside of emacs for debugging. This seems to work with the cross-development toolset for, e.g., ARM or other non-host development needs if you’ve got the appropriate cross-gdb toolset installed. (Which is ultimately what Eclipse uses, but much slower and with more bulk.)

    Driving the editor around is now embedded in muscle memory. If you asked me how I just did something clever in the editor (select a block of text and then re-indent according to the language mode), I’d probably have to watch my fingers to tell you the answer.

    Rather than assail your choice in editor (vim vs. emacs), I’ll simply import a rant equivalent by reference:

  2. I first learned vi and emacs in college. I absolutely concur that editing becomes a spinal reflex in these tools :)

    I found the concept of “mode” to take awhile to acclimatize to, having started with MicroEmacs. Actually it was more of a dogmatic hatred of vi for years — eventually I learned to appreciate both.

    Sort of like Mac vs PC, Unix vs VMS etc. They’re all tools with their place and each are interesting in their own right.

    I guess I’ve never truly tapped the code editing capabilities of vi using it mostly for editing scripts and config files on unix; I use Emacs for code (well, actually now I use Notepad++) but it’s probably worth looking into vi further and see what I’ve been missing.

  3. So right! Also, after a while you start wondering how you could ever use such a moloch like Eclipse. Don’t get me wrong: such IDEs are very powerful tools, but in the time Eclipse takes to start up after a reboot, I’ve edited three files with VIM … One more suggestion for learning VIM: type vimtutor in terminal, this will bring up a quite good (builtin, of course ;-) tutorial. That litte script works at least on diverse Linuxes and Snow Leopard.

    P.S.: I am missing the note about Emacs being a quite usable operating system — lacking a proper editor

  4. I use vim to edit C and Python. The choice for indentation in Python is 4 spaces rather than tabs.

    If you’re in the same boat, add these to your .vimrc or _vimrc (in win):

    set tabstop=4 set sw=4 set autoindent set expandtab set softtabstop=4

    Now instead of actually typing 4 spaces in edit mode, just press [tab] which does it for you. Similarly, pressing [backspace] in front of 4 spaces will delete them (if they’re at the beginning of a line). Also, use >> or << in command mode to indent a line. Combine with marking blocks (ma <<‘a) or 10>>a for indenting the next 10 lines.

    Macros are your friend (qa @a). Start at the beginning of a line , press qa then records all the keystrokes you would do to transform the line, end with 0j (go to the beginning of the next line), press q again, then 100@a will process the next 100 lines using your defined macro.

    As well as splitting the vim screen into multiple files (:sp filename or :vsp filename then ctrl-w w or ctrl-w W to navigate) vim also has tabs. :tabnew to create a new tab, then gt or gT to move between tabs.

    Like JC said, there are virtually hundreds of commands which will make your life easier. In the 17 years I’ve used it (and vi before that), I’ve probably only scratched the surface. To learn new commands, do check how other people use vim (blogs etc…) or cheatsheets.

    finally, add this to your .vimrc:

    set visualbell

    your colleagues will thank you ;)

    Cheers, Egor

    • In the 17 years I’ve used it (and vi before that), I’ve probably only scratched the surface.

      That’s the weblog post in a nutshell :) – it can be a journey and lifelong commitment, which also explains why vim won’t go away: too many people have internalised it!

  5. I have been using vi(m) for over 20 years. It was probably the one editor you could rely on to be on every unix/linux machine you needed to login to over the network. (ok emacs maybe , though it wasn’t always installed on solaris etc.. out of the box). This always meant a lot as you didn’t have to relearn anything to be productive.

    I have always found big IDE’s like Eclipse to be such resource hogs. And for some reason I am always running on memory constrained systems ;-)

  6. Sad and unambitious, I know, but I stick to nano(!) for basic stuff and geany for GUI stuff. Works for me.

  7. The original code for vi was written by Bill Joy in 1976. “Why do you need a gui if it runs on the command line ? ” ;-)

  8. You’ve probably seen this, but lots of good info at, and the author also has a book that is pretty good (Practical VIM).

    • Thanks, yes. Am leafing through that book once in a while. I like how he doesn’t go overboard with extensions and plugins.

  9. +1 for the Practical VIM book. I’ve used Vim , Vi and Emacs for many years but just yesterday was reading the book to remind myself about using exuberant tags. Very nice when reviewing a large project.

  10. I’ve been using vim for about 6 years now and I still feel that I have a lot to learn. There’s always that one keystroke just discovered that saves so much time. Lately I’ve drawn a lot of good plugin ideas from various dot file repositories like and Another site that always reminds me there is much more to learn is

Comments are closed.