Vim for People Who Think Things Like Vim Are Weird and Hard

Written by Harry Roberts on CSS Wizardry.

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…

I’ve been quite an avid and exclusive user of Vim for a couple of years now, and in that time I’ve seen quite a lot of misinformation and misguided vitriol (for want of a better word) for what is by far the best text editor I have ever used.

This post aims to cover how Vim is:

• Widely available
• Customisable and extensible
• Modal, for making you efficient across all manner of tasks
• Very literal
• Built entirely on keyboard shortcuts
• Highly composable
• Very minimal

This post isn’t here to teach you how to use Vim; it exists to teach you why to use Vim. If you want to learn Vim, which you should (and you’ll hopefully want to after reading this post), the simplest way to get started is:

1. Open up your Terminal and simply run $ vimtutor. This is a really simple step-by-step tutorial covering the basics of moving around and changing files. It gets progressively more advanced, but never gets hardcore. It’s actually quite fun, especially when you feel the pieces slotting into place.
2. Look up the many Vim cheatsheets out there in order to learn Vim’s ‘alphabet’. This should begin to show you how each letter on the keyboard usually maps to a function that starts with the same letter, for example, d means delete, c means change, and so on. The main cheatsheet here is one of the better ones I’ve seen.
3. Google the rest. The trick with things like Vim (and Git, etc.) is just knowing enough to know what to ask Stack Overflow.

N.B. The title of this post is a nod toward Chris Coyier’s 24 ways post Grunt for People Who Think Things Like Grunt are Weird and Hard.

In the Beginning

Most peoples’ introduction to Vim starts the same way: Why on earth would you use this? It’s how old?! You have to type what to quit it?!

The mere concept of Vim is alien enough for most people to just end up dismissing or ridiculing it, but—if we’re to be objective—the fact that, yes, people still use an editor that is over 20 years old (in turn based on a tool from the 70s), and those people number in the hundreds of thousands, perhaps they might be onto something. Approaching something like Vim needs a fairly open mind, and to look at things a little more closely and objectively. Once I began asking why do people use Vim?, rather than why on earth do people use Vim?!, it began to make a lot more sense to me. And here I am now, a couple of years later, extolling its virtues myself.

But, I was that guy—I couldn’t work out what was so bad about using a mouse, what was so wrong with TextMate? How on earth do you remember all these combinations? How can you find such convoluted commands so useful?

(The short answers to those questions are:

• If you spend 90% of your time typing, reaching for a mouse in order to complete certain tasks is a pretty big dent in concentration and focus.
• There’s nothing wrong with other editors per se, but Vim has a lot of advantages over them.
• Vim is very literal. d means delete, c means change, a means append, which means you can ‘speak’ your commands out loud: dit means delete inside tags; ciw means change in word, gUe means go uppercase to the end of the word, and so on.
• Commands are not convoluted, they are composed. The commands in the above list item can be deconstructed and recombined to do the same things in different ways: changing dit to cit means change in tags, instead of delete in tags. By learning Vim, you learn a handful of commands, and then you are free to combine and compose them in many different ways in order to achieve any number of tasks.)

I’d watch friends using Vim and be perplexed as to why you’d possibly ever need to type <Esc>ggdG to delete the entire contents of a file. How on earth can something so bizarre do that? How on earth do you remember that? In what world does that even make sense?!

In fact, the <Esc>ggdG example is a great demonstration of misconceptions and misinformation in Vim world. The command to delete the entire contents of a file is simply dG: delete and Go to the bottom of the file. What <Esc>ggdG actually does is:

1. <Esc> ensures you’re in the correct mode.
2. gg moves your cursor to the top of the file.
3. d tells Vim to prepare to delete.
4. G tells Vim to go to the bottom of the file (whilst deleting, as per the previous command).

The reason someone would use (or rather, tell you to use) the more verbose <Esc>ggdG command is that it’s the defensive version; it’s the version that will always work, no matter where in the file, or in which mode, you are.

So, one of the first things to note is that ‘verbose’ commands to do one thing usually aren’t doing one thing at all.

We’ll read later on how Vim is highly composable. The command <Esc>ggdG will very robustly delete the contents of an entire file, but let’s say we want to auto-format the contents of an entire file. That would be <Esc>gg=G: we swap out delete command for =, which means format. We want to indent the entire file by one tab? <Esc>gg>G: we swap out the delete command for the indent one >).

It’s very, very important not to take Vim commands at face value; they’re usually presented as part of a much bigger, more defensive, more bulletproof chain of commands. This is all part of Vim’s composability.

Learn Your Text Editor

It might feel a little counterproductive to introduce a learning curve to something as basic as a text editor, but if you’re going to spend up to eight or more hours a day in there, you should know it inside out (Vim or otherwise). It astounds me that I still see people—professional web developers—fudging their way around the tool that pays their wages; a text editor should be learned.

Starting with Vim is hard. It’s not fun, and it makes you feel stupid (especially if someone is watching over your shoulder) but, as with most new things, there will always be a learning curve. With Vim, however, I have found that the curve never begins to plateau—you can learn ‘just enough’ in an afternoon, but there’s always something more you could learn, or an even more efficient method you can work out.

Widely Available

Getting stated with Vim is easy: it’s installed on every Unix-like system right out of the box. Buy a new Mac? It already has Vim on it. Using someone else’s machine? They have Vim on it. Working on a remote server? It has Vim on it. Using Windows? Sorry :(

This is great for people who pair program a lot—you can use Vim on anyone’s machine. The amount of times I’ve been working on someone’s computer and been able to fire open Vim and be at home with it right away is really great. It’s especially handy for Ops Engineers, who spend a lot of time working on and configuring boxes all over the place; being confident in knowing your text editor is already on that machine means you can work in confidence and comfort.

Another huge benefit of Vim’s ubiquitous nature is, to put it bluntly, money. That’s not to suggest that it’s not worth spending money on a text editor—I firmly believe that you should invest in things that will make you more productive—but I really do not miss the pain involved in getting a new machine, and having to go through any (or all) of the following:

• Getting line managers to approve a payment for a text editor (it’s not about the amounts involved, more the hassle and paperwork).
• Trying to find old license keys for software I rightfully bought.
• Emailing software vendors asking if I can transfer license keys to new machines.
• Having to find the company credit card, record an expense, etc. etc.

I know that Vim is free, it’s open source, it’s already on my machine, and I control any of its configuration.

Customisable and Extensible

Out of the box, Vim is very simple and surprisingly powerful; it focusses only on being a fantastic text editor. That said, you do have the option to massively customise and extend it to better suit your own preferences.

The simplest way of doing this is through dotfiles; small text files that (usually) sit invisibly in your home directory. By creating and populating a .vimrc file, you can set your own custom key bindings, preferences, settings, functionality, UI tweaks, and more. A quick look at my .vimrc shows you that I’m not doing anything particularly crazy, but I have set up a few nice-to-haves, like my own preferences for spaces for indents, and their quantity.

Dotfiles are a fantastic, very simple way of managing your settings, and, where Vim is concerned, are very complementary to its wide availability. Whenever I get a new machine, I know it will already have Vim installed on it, and that I can simply save my .vimrc onto this new machine and that’s it; my text editor is exactly the way I like it, immediately.

Extending Vim is also one of its core principles—plugins can be written in a number of languages, meaning all manner of developers can have a go at writing extensions. Currently, I don’t write or even use any plugins. I find that relatively-vanilla Vim is more than enough for me right now, but plugins are certainly something I should start looking into once I feel out outgrown Vim’s default offering.

Modes

One of the initially most confusing things about Vim is its modes, which include, but are not limited to:

• Normal, which is the ‘normal’ mode for Vim—the one that you’re in whenever you open a file.
• Insert, which is the mode you would enter to type stuff.
• Visual, which is a mode in which you can perform all types of highlighting trickery in order to select text.

The need for modes might feel quite odd, but a lot of developers—myself included—don’t just write code: we read it, we scan it, we review it, we check it. Normal mode is a mode that I spend a lot of time in. It provides me with a way to quickly look through large (and small) amounts of code very effectively. For example, I can page forward or backward through a large file using Ctrl+f and Ctrl+b respectively; I can jump my cursor a-code-block-at-a-time using { or }; I can go to the very bottom of an entire file with G; I can move my cursor to the highest, middle, or lowest visible line by hitting H, M, or L respectively.

But command mode isn’t just for for moving around code; it’s for executing many different Vim commands. I can simply skip to the highest currently visible line by hitting H, sure, but if I were to hit dH then my cursor would jump to the Highest currently visible line whilst deleting everything on its way there.

Normal mode is where most of the magic happens. This is why it’s the default mode, and the mode I spend most of my time in: manipulating code this way is fast. I mean, really fast.

You enter Insert mode only when you want to type something. If you’re deleting, indenting, yanking (Vim speak for copy) or putting (Vim speak for paste), you will not be in Insert mode. This is one of the most confusing things to initially get your head round: Insert mode is not the default mode, because—when you think about it—you typically spend less time actually typing characters than you do moving and manipulating them. You have to explicitly enter Insert mode before you can begin typing. There are several ways to enter Insert mode: the most common way is to hit i, but you could also hit append, substitute, or change-with-options (e.g. cit for change inside tags).

Visual mode is one I don’t spend that much time in, because (usually) you can delete, copy, change, etc. your code without needing to actually highlight it. V10jd (Visualise full lines, 10jumps down, and delete) will highlight the next 10 full lines, and then delete them. I can achieve the same thing by hitting 10dd (10 ddeletions of whole lines), which deletes the next 10 whole lines without needing them highlighted. That said, visual mode can be useful if you don’t necessarily know the exact number lines you want to delete, but you know that you could highlight up to a point you can visualise.

Modes are a great way to work through different tasks on your code without ever leaving your text editor, or even your keyboard. For me, who spends a lot of time reviewing other peoples’ code, being able to navigate it easily is a must.

Very Literal

One of the best things about Vim, and one of the things that makes it quite quick to learn and work with, is that its commands are very literal. So much so that you pretty much tell Vim what to do in human terms:

• diw is delete inside word.
• cat is change around tags.
• f> is go forward to a closing chevron (>).
• vi" is visualise inside quotes (").

Being able to work like this means that—once you’ve memorised a handful of commands—you can piece together sentences which tell you exactly what you’re going to type; want to delete inside a sentence? Guess what: that’s dis. Want to visualise around some parentheses? va(. Go uppercase to the end of the current word? gUe.

This method of thinking about how you want to manipulate your text, and then Just Doing It™, gives rise to the phrase editing at the speed of thought. No matter how complex your operation might seem, think it, and you can do it.

Keyboard Shortcuts

We all love keyboard shortcuts, right? Right. We all cringe every time we see someone use the mouse to head to Edit » Copy, Edit » Paste, right? Right.

Keyboard shortcuts make repetitive, boring tasks fast. They save us time, and make us more efficient. Vim is just keyboard shortcuts. No mouse, no UI menus, no dropdowns, no buttons; just keyboard shortcuts. Everything in Vim is a typed command.

As you can probably already see, Vim puts keyboard shortcuts on steroids. I wouldn’t even like to guess how I might go about deleting the contents of a set of HTML tags, and then duplicating the new empty tags 10 times in Sublime text without reaching for my mouse, or hitting a lot of arrow keys. In Vim, it’s as simple as dit to delete the contents inside of the tags, and then yy10p, to yank (copy) the next current line (the opening and closing tags) and then put (paste) 10 new ones. Even very specific tasks like that all map back to keyboard shortcuts.

To handle something as specific as that all from the keyboard makes editing so much faster than without, and being able to drive your entire editor without ever leaving the keyboard makes you surprisingly productive.

Highly Composable

As we’ve briefly looked at, one of Vim’s core principles if that of composition. Vim has loads of tiny, single responsibility commands like delete, yank, put, go, change, substitute, and so on. These commands, or verbs can be used alongside modifiers, like inside, around, or forward, which are then combined with nouns, like sentence, tags, word, etc. Further, we can prepend most things with a number: 10dw will delete the next 10 words. 5c{ will change the previous 5 blocks ({).

This level of composability yields fantastic results. Think about Subway for a moment. Subway, the sandwich place. They offer an array of ingredients, all laid out in front of you. These ingredients are very versatile, because they’re very easily combinable. You can make over a million different sandwiches at Subway out of the same common set of ingredients. Offering up these much smaller component-parts allows people to combine and compose an almost limitless amount of variations.

Anyone who is familiar with the Single Responsibility Principle will already see the huge, huge benefit this brings. Instead of rigid commands that only do one big, specific thing, we can piece together the bits we want as we want them. Subway operates on the Single Responsibility Principle in order to serve very customisable food via the same core ingredients.

Vim does this for text editing.

By offering a key set of initial, simple, single responsibility commands (ingredients), we can start to piece together our own tasks (sandwiches) in any combination we choose, to achieve very specific goals. If I know I can di{ (delete inside braces) I know I can therefore vi{, or ci{, or yi{, or gUi{. If I know I can do all that inside braces, I can presume that I must be able to do it all around them: da{.

Learning Vim isn’t about learning that <Esc>ggdG means enter Normal mode, go to the top of the file, delete to the bottom of the file, or that 3cit means change the contents of the three nested tags above my cursor, it’s about learning that we have a change command, we have modes we can be in or out of, we have go commands, we have delete commands, we have nouns like tag. All we do is learn these bits, and we piece them together exactly how we need them, when we need them.

The cognitive overhead of Vim is a lot lower than most people imagine, because people don’t realise that we’re just learning a common alphabet, and it’s up to us to write the words we want.

Very Minimal

Finally, I just like how plain and simple Vim is to look at and work with.

There’s a reason iA Writer is so successful: it’s beautifully simple. You just write. There’s no clunky UI to get yourself lost in, or to distract you. The same rings true for Vim. This is the interface I get to spend all day looking at:

Nothing superfluous, nothing ugly, nothing to distract me or get in my way; I just get on and work. This is very superficial, and nigh-on impossible to quantify, but I find this really helps me focus on whatever it is I’m working on.

Further Reading

• Jack Franklin runs a blog called TIL Vim through which he shares handy tips.
• Vim Adventures is a fun little game-style learning tool for Vim.
• Pascal Precht has a recent post entitled Why I use Vim.

Vimpressive!

After being a naysayer and detractor for a long, long time, I decided to give Vim a try. I worry that the reason a lot of people mock Vim is because they don’t fully understand it. Once I learned that Vim isn’t convoluted but composed, and that it’s basically just a physical extension of my train of thought, I am a lot more productive. Vim allows me to do what I’m thinking, and doesn’t make me think about what I’m doing.

If you’ve never tried Vim before, I urge you, just give it a go. It might feel alien at first, but that’s all part of the fun.

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…

By Harry Roberts

Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.