Vim for People Who Think Things Like Vim Are Weird and Hard – CSS Wizardry

23 June, 2014

Written by Harry Roberts on CSS Wizardry.

Table of Contents

1. In the Beginning
   1. Featured case study: NHS
   2. Learn Your Text Editor
2. Widely Available
3. Customisable and Extensible
4. Modes
5. Very Literal
6. Keyboard Shortcuts
7. Highly Composable
8. Very Minimal
9. Further Reading
10. Vimpressive!

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 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 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 ggdG
actually does is:

1. 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
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 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 gg=G: we swap
out delete command for =, which means format. We want to indent the entire
file by one tab? gg>G: we swap out the delete command for the indent
one >).

Featured case study: NHS

How I helped the NHS rapidly build a brand new product.

Read case study…

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 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

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.