This post won’t be for everyone. In fact, it may well sound like an utterly ridiculous idea…
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:
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.