Vim’s most useful command is noticing the edit you keep repeating

Sebastian Bergmann photographed Vim creator Bram Moolenaar in 2007, the year of the Google talk examined here. Wikimedia Commons, CC BY-SA 2.0.[6]

The recording looks like a time capsule: a 4:3 frame, a projected Vim 7 screen, and a room listening to completion features that were then new. Yet Bram Moolenaar’s February 2007 Google talk has aged better than a tour of old software should. Its durable subject is not a particular key binding. It is how a person improves a tool-mediated craft without turning improvement itself into a hobby.[1][2][5]

Moolenaar reduces that problem to a loop: detect an inefficiency, find a quicker way, and make the new way a habit. The sequence matters. It begins with work you actually do, not somebody else’s list of “must-know” commands. It ends with practice, not discovery. A clever command seen once is trivia; a modest command recalled at the right moment changes the shape of repeated work.[1][2]

That makes this talk worth watching even if Vim is only a compatibility layer inside another editor—or not your editor at all. The examples are recognizably Vim, but the stronger idea is portable: improve the recurring edit, choose the smallest mechanism that removes its friction, and stop optimizing when the return disappears.

Around 4:00: the real interface is a feedback loop

The talk’s governing slide appears around the four-minute mark. “Detect inefficiency” comes first because optimization without observation is guesswork. “Find a quicker way” comes second because naming a nuisance does not remove it. “Make it a habit” comes last because the old path remains cheaper in the moment until repetition lowers the recall cost of the new one.[1][2]

This is also a guardrail against two familiar failures. The first is refusing to pause because the current document feels urgent; every future document then pays the same tax. The second is attempting to learn an editor exhaustively. Moolenaar’s accompanying material warns that mastering every feature is not the same as being effective: unused knowledge has an acquisition cost too.[2]

A useful engineering reading is to rank friction by three properties: frequency, cost, and repeatability. A clumsy action done twenty times a day is a stronger candidate than a spectacular trick needed twice a year. A deterministic edit is a stronger automation target than a judgment-heavy one. This ranking is an inference from Moolenaar’s loop, not a benchmark claim, and it keeps the method honest: the point is less avoidable effort, not fewer keystrokes at any price.

Around 9:30: name the destination instead of counting the distance

In the first habit, “moving around quickly,” Moolenaar shifts from detecting slow navigation to searching for a better route. By roughly 9:30, the slides have moved to search highlighting and word-based search; a little later, the demonstration uses folds to collapse a large file into meaningful regions.[1][2]

The shared idea is addressability. Repeated cursor steps describe distance: down seventeen lines, across four words. Search, matching delimiters, marks, tags, and folds describe a destination: the next occurrence, the paired brace, the named place, the hidden region. Vim’s user manual reflects this distinction by treating movement, search, editing, repetition, folding, and program navigation as related systems rather than a flat shortcut sheet.[3]

That does not make every semantic jump superior. When the target is already visible and close, a plain motion may carry the lowest mental cost. The improvement appears when counting or scanning recurs. Then the text itself can become the coordinate system. The lasting lesson from the old folding demo is not “always fold code”; it is “give repeated destinations stable names.”

From 12:00 to 16:00: “don’t type it twice” is a ladder

The second habit begins near 12:00 with an awkward identifier that is slow to type and easy to mistype. Moolenaar climbs through progressively stronger responses: use completion for words already present, then use filetype-aware omni completion when the language context can supply a narrower answer. The omni-completion demonstration arrives at about 15:00.[1][2]

Read as a ladder, the section is more useful than a feature comparison. Vim can reuse the last change, complete a token, expand an abbreviation, replay a register, or run a script. Those mechanisms do not merely differ in power; they differ in setup cost, visibility, and failure radius. Repeating one safe change with . is cheap and local. A recorded macro is broader but still inspectable. A permanent mapping or script can save more work, while also becoming configuration that somebody must remember and maintain.[3]

The practical rule is to escalate only when the repetition earns it. Start with recall already built into the editor. Promote a sequence into automation after its shape stabilizes. If exceptions dominate, keep the human in the loop. This is where the talk quietly resists tool tourism: installing a larger completion system is not an improvement when the recurring problem was simply retyping a word already on screen.

From 20:00 to 31:00: the document is larger than its buffer

At about 20:00, “a file seldom comes alone” expands the unit of work. The examples move through tags, gf for following a filename, include-file searches, and the quickfix window. A few minutes later, :make or :grep results have become entries a user can jump through. Near 30:00, a new example treats noisy lint output as structured text and filters recurring warning patterns with a small cleanup function instead of scanning every line by hand.[1][2]

These scenes reveal a second kind of addressability: translating external structure into locations the editor can visit. A tag links an identifier to a definition. A quickfix entry links diagnostic output to a file and line, often with a column. Neither feature needs the editor to own the compiler, repository, or language. Vim becomes useful at the seam because it can consume their references.[3]

The lint filter adds a caution. Structured output can be transformed, but a rule that suppresses familiar noise can also conceal a warning whose meaning has changed. Once a cleanup command enters the habitual path, it deserves the same review as any other small program: narrow patterns, visible output, and an easy way to inspect what was removed.

Modern language servers and IDEs offer richer versions of this experience, but the boundary principle remains valuable. Ask what system owns the truth, what representation crosses into the editor, and whether the jump can be reproduced. A clickable diagnostic backed by a build result is stronger than a clever interface that hides where its answer came from. The 2007 commands are old; the integration test is not.

Around 36:00: sharpening should answer observed friction

The seventh habit gathers folding, indentation, plugins, network editing, and scripting under “sharpen the saw.” At roughly 36:00, the breadth of that list could be mistaken for an invitation to configure forever. The earlier three-step loop says otherwise. Sharpening begins with observed drag and ends when the replacement becomes dependable.[1][2]

That boundary is especially important for teams. A personal mapping can be almost free for its author and opaque to everyone else. A shared script needs naming, review, documentation, and an owner. Editor automation should therefore be evaluated like any small internal tool: how often it runs, what happens when it is wrong, whether its behavior is visible, and who repairs it when the surrounding workflow changes.

Vim is not a universal productivity verdict. The Linux Foundation’s beginner guide makes the learning investment explicit and notes that people without sustained text-editing or system-administration needs may reasonably decide it is not worth paying.[4] The same is true inside Vim: a command that never becomes recallable has not removed friction; it has moved friction into memory.

The talk’s best contemporary use is a one-week experiment. Notice one edit that repeatedly interrupts thought. Find one smaller, safer way to express it. Use that way deliberately until it either becomes ordinary or proves too costly to retain. Keep the improvement only if it reduces effort or mistakes in real work. That is a less glamorous promise than “master your editor,” and a much more credible one.

cronfeed.work