Lesson 2 — Moving Around

You are six lines into a prompt for a coding agent and the wrong word is back at the start. Or a dev server has printed a URL four rows up, wrapped across two lines, and you want it — not most of it, not it plus the bracket after it. Both are the same question: how do I get over there?

That question has an answer in a code editor — click. In a terminal it has never had one, which is why a long prompt gets abandoned and retyped rather than fixed. Motions are the answer, and they work the same whether you are moving through your own half-written prompt or through a screenful of output.

Motions are also half of everything in Lesson 3. Every edit and every copy is an operator plus a motion, so the keys below are not a separate topic you learn later — they are the vocabulary. Learn where, and the what comes free.

One thing worth knowing before you start: in a terminal, moving around never reaches the program. You can read back through the output while a command is still running, and nothing in this lesson can disturb it.

The four keys under your fingers

h left, j down, k up, l right. They are under your right hand on the home row, which is the whole reason they were chosen. j has a downward tail if you need a mnemonic.

The arrow keys still work in normal mode, so nobody is forcing you. But the arrows are a trip off the home row on a laptop and, on a phone, they are barely there at all — which is where this pays.

j and k remember the column you started in. Move down through a ragged block of output and you come back out at the column you left, not squashed against the end of the shortest line.

Where this works: both halves — code editors and terminals.

Words, and WORDs

This is the centrepiece of the lesson, and the one habit worth forming today.

w moves forward a word, b back a word, e to the end of the word you are on. A "word" here is a run of letters and digits — punctuation ends it.

W B E do the same job with a bigger idea of a word: a run of anything that isn't a space.

The difference is not academic. Consider a URL in your output:

https://example.com/docs/vim-mode

A URL is one W but seven ws, because w stops at every slash, dot and hyphen. Same for a file path, a version string, an email address, a flag like --dry-run — everything a terminal is actually full of.

So the rule of thumb for terminal work is: reach for W B E first, and drop to the small ones only when you genuinely want to land inside a word. Lesson 4 turns this into yiW — "copy that whole URL" — and that single key difference is why it is worth building the reflex now.

In a terminal, w also falls onto the start of the next line when it runs out of road, which makes it a decent way to scan forward through output rather than only along one line.

Where this works: all six in both halves. The WORDs earn their keep hardest in a terminal — it is where the paths and URLs are, both in the output you are reading and in the prompt you are writing. b b to step back over two words of your own prompt is the motion you will use most often without thinking about it.

Along the line

^ is the one you want most of the time in a terminal, because indented output has leading spaces and 0 parks you in them.

These three are the ones you will wear out while writing a prompt: ^ to get to the front of a long one and add a missing word, $ to get back to the end and carry on. On a phone they replace a hold on the arrow key that always overshoots.

"The line" means what you typed, not the row it is drawn on. A prompt too long for the screen is one line shown across several, and 0 ^ $ treat it as the single thing it is — ^ from the third row still goes to the front of the command. Up in the output the two are the same thing anyway, because the program printed each row as its own line.

Where this works: both halves.

Top and bottom

gg goes to the top, G to the bottom. In a code editor that means the file. In a terminal it means the scrollback — gg is "take me back to where this command started", G is "back to the prompt".

A count in front of G goes to that line instead: 120G. In a code editor there is a second way to say the same thing — the command line, :42 — which Lesson 3 covers.

Where this works: both halves.

Blocks of output

} jumps forward to the next block of text; { goes back to the top of the block you are in, and then to the top of the one before it. In a code editor that is a paragraph or a stanza of code.

They land ON the block, not on the blank line between blocks. Vim itself stops in the gap, which costs you a j every single time — because yip on a blank line copies the blank lines. Here } then yip does what it reads like.

In a terminal it is better than that. Output arrives in blocks separated by blank rows, so a block is usually exactly one thing: one command's output, one stack trace, one reply from an agent. { and } step between them like chapters. It is how you get from "somewhere in the last screenful" to "the top of the answer" in one key.

Where this works: both halves.

Jump to a character

f plus a character flies to the next one of those on the line. t stops just before it. F and T are the same two going backwards.

Then ; repeats that search forwards and , repeats it the other way, so overshooting costs one key rather than a retype. (, really does flip the direction: after f, a , searches backwards.)

Landing on a slash with f/ is often the fastest way into the middle of a path. And these compose with operators, which is where they earn their keep: dt/ and yf. are both ordinary sentences once you have read Lesson 3.

Where this works: all six in both halves. In a terminal the search stays on the row you are on, which is exactly the shape of the job.

Matching brackets

% jumps between a bracket and its partner — ( ), [ ], { }, < >. You do not have to be standing on one: it looks forward from the cursor for the first bracket and jumps from there.

In a terminal it works along the row you are on, which is the right shape for the job — a JSON fragment or an argument list printed on one line.

Where this works: both halves.

Where you are on the screen

The motions so far move you around the content. These three move you around the view:

• H — the top line of what you can see
• M — the middle
• L — the bottom

With a count they mean "n lines in from that edge", so 3H is the third line down from the top. Because they are screen-relative, they mean the same thing however long the scrollback has grown — very handy for "the thing near the top of what I'm looking at".

To move by screenfuls:

Where this works: both halves. In a terminal they page through the scrollback, which is what makes them the ones you reach for after a long build.

Move the view, not the cursor

zt zz zb put the line you are on at the top, middle or bottom of the screen without moving the cursor off it.

In a code editor that is a comfort. In a terminal it solves a real annoyance: you search for something, you land on it, and it is sitting in the bottom two rows where a wrapped line and the next prompt are about to crowd it. zz and it is in the middle of the screen with room to read.

Where this works: both halves — but the annoyance it solves is a terminal one.

Counts multiply everything

Type a number before a motion and it happens that many times: 5j, 3W, 2}, 10k.

This applies to every motion on this page, and in Lesson 3 it will apply to operators too (3dw). A count is spent as soon as it is used — it never sticks around to surprise the next key.

One small trap worth knowing: 0 is "start of line" only when no count is being typed. In 10j the 0 is continuing the number, which is what you wanted.

Where this works: both halves.

Where each motion works

Here is the good news for a lesson that has just thrown twenty keys at you: motions are the part of Vim where the two halves agree. Everything on this page works in a code editor and in a terminal. What changes is the territory a motion crosses — a file in one, the scrollback in the other. The differences start in Lesson 3, when you begin changing things.

This is the lesson recap. For the same rows alongside every operator, object and register, keep the cheat sheet open instead; the Vim Mode reference is the authority behind both.

Try it

Open a terminal with Vim keys on, run something that prints a good chunk of output — ls -la, or a build, or ask a coding agent a question — and then:

1. Press Esc. The badge in the corner reads NORMAL.
2. Press gg, then G. You have just crossed the whole scrollback twice.
3. Press { and } a few times. Watch the cursor step between blocks of output rather than lines.
4. Find a line with a URL or a long path on it. Put the cursor at the start of it and press w repeatedly, counting the stops. Now go back with 0 and press W once.
5. Press f then /. Press ; twice to walk along the path a slash at a time, then , to come back one.
6. Press H, then 3H, then L. Then CtrlU to go up half a screen.
7. Move to a line near the very bottom of the screen and press zz. It jumps to the middle, cursor still on it.
8. Now the writing half. Press i and type a long prompt — a real one, a sentence or two for a coding agent — but do not press Enter. Press Esc, then ^ to shoot to the front of it, w w to walk in a couple of words, and $ to come back to the end. That is the trip you would otherwise make by holding an arrow key.
9. Press i to get back to typing — or tap the mode badge, which always does the same thing.

You now know: how to get anywhere — in a screenful of output, or in the long prompt you are part-way through writing — without touching a pointer. And, more importantly, the motion half of every edit and every copy in the lessons ahead.

Related

• Vim Mode — the full command reference
• Terminals
• Code Editor
• CLI Coding Agents
• Phone Key Row

← Lesson 1 — Modes · Lesson 3 — Operators, Counts and the Grammar →