DEV Community: Vimtricks.wiki

A safer Vim workflow before bulk text changes

Vimtricks.wiki — Mon, 30 Mar 2026 12:06:42 +0000

Big edits are where I make my most expensive mistakes: replacing too much, landing in the wrong spot, or clobbering the text I meant to paste later. Over time I ended up with a small pre-flight workflow in Vim that reduces that risk a lot. It is not flashy, but it saves me from cleanup commits and awkward "why did this file change?" moments.

These are the five commands I reach for most when I am about to touch a lot of text.

1) Dry-run a substitution count first

Why it matters

Before I run any large :s command, I want impact size first. Counting matches gives me a fast confidence check: "am I about to change 3 places or 300?"

:%s/TODO/DONE/gn

Real scenario

I am renaming a marker in a long file and my regex is slightly fancy. Instead of trusting myself at 11 PM, I run the gn version first. If Vim reports a suspicious number, I fix the pattern before touching content.

Caveat

The n flag reports counts only, so no text is changed. Still, make sure your pattern is exact; a broad regex can look "correct" while counting things you did not intend.

2) Keep your last yank safe with the black hole register

Why it matters

Deleting text right before a paste is a classic way to destroy the value you yanked two seconds ago. The black hole register lets you delete or change text without overwriting the unnamed register.

"_d{motion}

Real scenario

I yank a function name, jump elsewhere, then need to delete one word before pasting. Using "_dw deletes that word but keeps my yanked function name intact, so p still pastes what I expected.

Caveat

This is great when you intentionally do not want deleted text later. If you might need what you removed, use a named register (like "adw) instead of discarding it.

3) Land at the end of a match when searching

Why it matters

Sometimes you want the match, but you want the cursor at the tail of it for the next edit. Search offsets avoid the extra motion after every jump.

/TODO/e

Real scenario

I am scanning TODO markers and immediately appending context after each one. Landing on the final character of TODO means I can hit a right away instead of moving to the end manually each time.

Caveat

The pattern is still just TODO; /e only changes landing position. If you forget that, repeated n/N behavior can feel surprising at first.

4) Replace only the current line with shell output

Why it matters

For quick one-line transformations, this is faster than copying into another tool and pasting back. You can treat Vim as a focused terminal filter.

:.!tr '[:lower:]' '[:upper:]'

Real scenario

I have a mixed-case identifier list and need one line normalized to uppercase for a config key. Running :.!tr ... on that line does it in place and keeps me in flow.

Caveat

This runs an external shell command, so behavior depends on tools available on your machine. Keep it for trusted commands, and avoid it on untrusted text pipelines.

5) Save only changed files across the arglist

Why it matters

After multi-file edits, :argdo write can touch files that were never modified, which creates unnecessary timestamp churn. update writes only buffers that are actually changed.

:argdo update

Real scenario

I run a refactor across 40 files, but only 11 really changed. :argdo update saves exactly those 11, so file watchers and git history stay cleaner.

Caveat

This works on the current argument list, so scope matters. Check :args first, or build the list carefully with :argadd before running batch commands.

Wrap-up

My default safety loop is simple: estimate first, edit deliberately, then write only what changed. These commands remove friction without adding ceremony, which is exactly what I want during real work.

If you want more practical Vim tricks, I publish them at https://vimtricks.wiki.
What is your go-to command for making bulk edits safer?

How I do safer multi-file edits in Vim

Vimtricks.wiki — Mon, 23 Mar 2026 12:06:55 +0000

Bulk edits are where even experienced Vim users can accidentally create a mess: too-wide matches, noisy jump history, or a replacement that looked right three files ago but is wrong in this one. Over time, I ended up with a short workflow that keeps speed high without giving up control.

This is the sequence I use when I need to change code across a project but still keep context and sanity.

1) Build a literal quickfix list from the current word

Why it matters

Before changing anything, I want a tight target list. If the first search is sloppy, every step after that becomes cleanup work. :vimgrep with \V gives me a literal search and sends matches straight into quickfix so I can inspect what I am about to touch.

:vimgrep /\V<C-r><C-w>/gj **/*

Real scenario

You are renaming a function like process_order across a service and want an editable hit list first. Run the command on the symbol, open quickfix with :copen, and skim entries before applying any change. That 15-second pass catches the obvious false positives early.

Caveat

<C-r><C-w> inserts the current word under cursor, not arbitrary punctuation-heavy text. If you need broader text insertion, switch approach (for example <C-r><C-a> for WORD-style text) and still keep the literal \V behavior.

2) Apply quickfix-wide substitution without polluting state

Why it matters

Once quickfix is curated, I want batch changes that do not wreck my navigation tools. This command applies the replace, writes only changed files, and avoids clobbering jump and search state while it runs.

:cdo keepjumps keeppatterns %s/\<OldSymbol\>/NewSymbol/ge | update

Real scenario

You searched for a deprecated API name and got 60 entries in 18 files. After confirming the list, run this once to replace exact word matches and persist edits. Then use quickfix navigation again to spot-check updated call sites.

Caveat

cdo executes per quickfix entry, so this can repeat work inside the same file. If your operation should run once per file instead of once per match, use :cfdo.

3) Use selective replacement when global replace is too risky

Why it matters

Not every rename is safe to automate globally. Some matches need changing, others must stay. The * + cgn flow gives me speed with per-match judgment, and . keeps it fast after the first replacement.

*
cgnnew_name<Esc>
.

Real scenario

You are changing count to item_count, but count_total and discount should stay untouched. Start on the first exact count, run the sequence, and press n to skip contexts you do not want before using . again.

Caveat

This flow depends on the active search pattern. If your last search is stale, hit * again on the exact token you intend to change before continuing.

4) Walk older edits with context restored

Why it matters

After a multi-file pass, review speed matters. Jumping by changelist alone is useful, but hidden folds and poor viewport placement slow verification. Chaining these motions gives me a dependable “show me the last real edit here” move.

g;zvzz

Real scenario

You made several edits in a long file and want a final sweep before commit. Repeating this sequence walks backward through changes, opens folds when needed, and centers each location so you can validate intent quickly.

Caveat

g; walks changelist entries, which are not a semantic diff. For project-wide review, I still pair this with quickfix, :changes, or git diff depending on scope.

5) Add a temporary line prefix across a matched set

Why it matters

During debugging, I often need to disable or mark lines quickly without visual-block gymnastics. :global with :normal scales that action from one line to many using a clear match rule.

:g/^/normal I//

Real scenario

You want to comment a copied block during an experiment, run tests, then revert cleanly afterward. One command prepends // at the first non-blank position across matching lines, keeping indentation readable.

Caveat

As written, this targets every line matched by ^, including empty lines. Narrow the pattern when needed (for example :g/^\s*\k/normal I//) to avoid touching blank separators.

Wrap-up

This workflow is simple on purpose: build a precise list, batch safely, switch to selective edits where needed, review quickly, and use repeatable linewise transforms for temporary changes. The commands are small, but together they reduce the two expensive problems in refactors: accidental changes and slow verification.

If you want more practical Vim tricks, I publish them at https://vimtricks.wiki.
What part of multi-file editing in Vim still feels fragile in your workflow?

How I clean many files in Vim without losing context

Vimtricks.wiki — Mon, 16 Mar 2026 12:07:49 +0000

Batch edits usually fail in the boring parts: navigation state, whitespace noise, and output I forget to capture before moving on. When I have to sweep through multiple files, I want a workflow that is fast but still reversible when I spot a mistake.

These are five built-in commands I use together for that exact job.

1) Remove blank lines before doing anything else

Why it matters

Blank and whitespace-only lines add visual noise, make diffs harder to review, and often hide real structure problems. I usually clean them first so every later change is easier to inspect.

:g/^\s*$/d

Real scenario

I paste a generated config snippet into a repo and it comes with random empty lines between sections. Running this once gives me a compact file before I start renaming keys or moving blocks.

Caveat

This is destructive for intentional spacing (like markdown readability blocks). If spacing is meaningful, run it on a visual range or specific section instead of the whole buffer.

2) Save-and-advance inside a macro-driven file pass

Why it matters

When processing files one by one, context switching is what burns time. :wn lets a macro finish each file, write changes, and jump to the next entry in the argument list in one step.

:wn

Real scenario

I load target files with :args **/*.md, record a macro that does a focused cleanup, and end it with :wn. Then 99@q walks forward until there are no files left.

Caveat

:wn expects an argument list. If you forgot to set :args (or reached the last file), Vim will stop with an error. I usually test the macro on two files first.

3) Reindent the entire buffer without polluting jumps

Why it matters

Whole-file reindent is common after edits, but it can trash your jump history and make review navigation annoying. :keepjumps preserves your jump/changelist context while still applying the indent pass.

:keepjumps normal! gg=G

Real scenario

After replacing tabs/spaces in a script, I want one consistent indent pass. This command reindents from top to bottom, and Ctrl-o still takes me through my real investigation path instead of formatting jumps.

Caveat

normal! intentionally ignores mappings. That is usually what you want for deterministic automation, but call it out in team docs if teammates rely on custom mapped behavior.

4) Capture command output into a register for reuse

Why it matters

Debug output often flashes by and disappears from working memory five seconds later. Redirecting :messages into a register turns transient output into editable text you can paste, diff, or search.

:redir @a | messages | redir END

Real scenario

I run a batch command, get a few warnings, then need those exact lines in a scratch buffer while fixing issues. After redirecting, I paste with "ap and work from concrete evidence instead of memory.

Caveat

Only one redirection can be active at a time. Always end with redir END; otherwise later command output may keep going to the wrong place.

5) Yank to a searched target without entering Visual mode

Why it matters

Visual selection is fine, but for repetitive structural edits I prefer operator + motion. y/{pattern}<CR> is quick, precise, and easy to replay.

y/{pattern}<CR>

Real scenario

I need to copy from my current cursor position to the next END_BLOCK marker repeatedly in a large template file. Using search as a motion keeps my hands in normal flow and works nicely with counts and repeats.

Caveat

Search motions are exclusive by default, so the matched text is not included in the yank. If you need the match too, adjust the pattern or yank one extra motion after confirming the boundary.

Wrap-up

This set works well as a practical sequence: remove junk lines, run a repeatable per-file macro pass, reindent safely, capture diagnostics, and copy targeted ranges without modal detours.

If you want more practical Vim tricks, I publish them at https://vimtricks.wiki.
What part of your current multi-file editing workflow still feels fragile?

A Vim workflow for safer bulk text edits

Vimtricks.wiki — Sun, 15 Mar 2026 19:23:38 +0000

Most refactor mistakes I make are not syntax errors—they’re scope errors. I change too much, target the wrong region, or apply the right command in the wrong mode. Over time I ended up with a small set of Vim commands that make bulk edits faster and less risky.

Here are five that I keep reaching for when I need to change many lines without turning my buffer into archaeology.

1) Run a controlled multi-file replace with the argument list

Why it matters

When you need a rename across many files, a one-liner can save minutes, but only if it is scoped correctly. Using the argument list keeps the target set explicit, and :update writes only changed files.

:args **/*.py | argdo %s/\<old_name\>/new_name/ge | update

Real scenario

I’m renaming a helper used across a Python package. I first narrow the scope to **/*.py, run the substitution with word boundaries, and let :update save only files that actually changed. That avoids touching timestamps in unrelated files.

Caveat

Double-check the file glob before executing. :args defines the blast radius. Also, use the e flag in %s///ge so files without matches do not interrupt the run.

2) Force a linewise motion to behave characterwise

Why it matters

Operators like d, c, and y inherit the motion type. Sometimes that is too broad. The operator-pending v modifier gives you precise control when a normal linewise motion would delete more than you intended.

dvj

Real scenario

You’re on a long line and want to delete down one screen line without wiping full lines. dj is linewise and aggressive. dvj forces characterwise behavior, so the delete ends at the corresponding position on the next line.

Caveat

With forced characterwise behavior, linewise motions become exclusive. Test once on a disposable line if exact endpoint behavior matters for a macro.

3) Use expression replacement for arithmetic substitutions

Why it matters

Simple text replacement breaks down when each match needs computed output. Vim’s \= replacement lets you evaluate an expression per match, which is perfect for version bumps and numeric rewrites.

:%s/\(\d\+\)/\=submatch(1)+1/g

Real scenario

You have a config file with repeated numeric thresholds and need to bump all of them by one. Instead of editing line by line or exporting to a script, one substitution updates every matched number in place.

Caveat

This matches any digit sequence, so scope it first if needed (range, pattern, or visual selection). Otherwise you may increment numbers you did not intend to touch.

4) Change substitute delimiters when paths make slash-heavy patterns unreadable

Why it matters

Escaping every / in a path replacement is error-prone and hard to review. Switching delimiters makes the command easier to read and reduces typo risk.

:s#/old/path#/new/path#g

Real scenario

I’m updating include paths in a config line from /usr/local/... to /opt/.... With # as delimiter, I can see the pattern clearly and avoid backslash noise.

Caveat

Pick a delimiter that does not appear in your pattern or replacement. Vim supports many non-alphanumeric delimiters, but consistency in one command is required.

5) Skip directly to the Nth next search match

Why it matters

Repeating n ten times is slow and easy to lose track of. Count prefixes turn search navigation into a precise jump.

3n

Real scenario

After searching for a recurring token in a large log, I often want the third or fourth next occurrence, not the immediate one. Prefixing n with a count gets me there in one keystroke.

Caveat

n repeats the last / or ? search pattern and direction. Make sure your current search is the one you intend before using larger counts.

Wrap-up

These are not flashy tricks, but they are reliable pressure reducers when edits get broad. I use them to keep scope visible, lower typo risk, and avoid mode surprises while moving fast.

If you want more practical Vim tricks, I publish them at https://vimtricks.wiki.
What’s your current “high-risk” edit that you still do manually?

Vim commands I reach for when simple edits get complex

Vimtricks.wiki — Fri, 13 Mar 2026 12:22:25 +0000

There's a point in most editing sessions where a simple substitution or a quick dd stops being enough. You're mid-refactor, your search history is getting polluted, your macro keeps running past where it should, or you just want to get back to the line you were editing five minutes ago. These are the commands I keep reaching for in those moments.

1) Matching only part of a pattern with `\zs` and `\ze`

Why it matters

The \zs and \ze atoms let you pinpoint which part of a match gets highlighted or replaced — without writing lookaheads or making the regex more complex. The surrounding context still needs to match, but only the portion between \zs and \ze counts as the actual match.

" Match the function name only, not the 'function ' keyword before it
/\(function\s\+\)\zs\w\+

" Substitute: rename only the value after 'color: '
:%s/color: \zsred/blue/g

Real scenario

You're grepping through a codebase for function definitions and want to rename all functions that follow the pattern process_* — but only the name part, not the keyword. Without \zs, you'd need a capture group and a \1 backreference. With it, you write:

:%s/\(function\s\+\)\zs\w\+/handle_data/g

Only the function name gets replaced. function stays intact.

Caveat

\zs and \ze are Vim-specific — they don't exist in POSIX regex or most other languages' regex engines. If you export a pattern for use in a script or shell command, you'll need to convert it to a capture group approach.

2) Substituting without losing your current search with `:keeppattern`

Why it matters

Every time you run :%s/foo/bar/g, Vim quietly replaces your active search pattern with foo. That kills your highlighted matches and sends n/N chasing the substitution target instead of what you were originally searching for. :keeppattern is a modifier that prevents this side effect entirely.

:keeppattern %s/old/new/g

Real scenario

You're stepping through a file looking at all TODO comments with /TODO and n. Mid-review, you realize a variable name needs a quick rename. Running a bare :%s/myVar/myVariable/g nukes your search context. Prepend :keeppattern and n still jumps to the next TODO after the substitute finishes:

:keeppattern %s/myVar/myVariable/g
" n still navigates to the next TODO — untouched

Caveat

:keeppattern works on any Ex command that normally updates @/, not just :s. But it only preserves the search register — if your substitution also changes the cursor position, that still happens. Worth knowing if you have mappings that depend on cursor state after a substitute.

3) Making a macro stop itself automatically with a recursive call

Why it matters

If you've ever guessed 99@q hoping a macro stops at the right line, this is the alternative. A recursive macro calls itself at the end of its recording. When any motion inside it fails — usually j hitting the last line — Vim aborts the macro chain. No guessing required.

" Step 1: clear register q so @q does nothing during recording
qqq

" Step 2: record the macro with a self-call at the end
qqA;<Esc>j@qq

" Step 3: run it
@q

Real scenario

You have a 300-line file of JavaScript variable declarations and need a semicolon appended to every line. You don't want to count the lines and you don't want to use :%normal A; (maybe the formatting logic is more complex than that, and you want the macro). Record once, run once with @q, and it processes every line and stops cleanly at the end of file.

Caveat

The qqq clear step is non-negotiable. If register q already contains something, @q during recording will execute that old macro mid-recording, and the result is unpredictable. Also make sure wrapscan is off (:set nowrapscan) if your macro includes a search — otherwise the macro wraps back to the top and runs forever.

4) Inserting computed values inline with the expression register

Why it matters

<C-r>= opens an expression prompt while in Insert mode. Type any Vimscript expression, press <CR>, and the result gets inserted at the cursor. It's a small feature with a surprising surface area: inline math, timestamps, current line numbers, shell output — all available without leaving Insert mode.

" Insert today's date
<C-r>=strftime('%Y-%m-%d')<CR>

" Insert the current line number
<C-r>=line('.')<CR>

" Quick math
<C-r>=1024 * 4<CR>

Real scenario

You're writing a config file and need to insert a timestamp for a created_at field. You could :r !date, but that inserts on a new line. With <C-r>=, you stay in Insert mode and drop the result exactly where the cursor is:

created_at: <C-r>=strftime('%Y-%m-%dT%H:%M:%S')<CR>

One keystroke sequence, no mode switching, no cleanup.

Caveat

system() works inside expressions, but it inserts a trailing newline. Use system('date')[:-2] or trim(system('date')) to strip it. Also, <C-r>= evaluates one expression — you can't run multi-statement Vimscript here. For that you'd use :call or a function.

5) Jumping back through your own edit history with `g;` and `g,`

Why it matters

Vim maintains a changelist for every buffer — a record of every position where text was modified. g; jumps backward to the previous change location; g, jumps forward. This is distinct from the jump list (<C-o>/<C-i>), which tracks cursor movement. The changelist tracks only actual edits.

g;    " go to older change
g,    " go to newer change
:changes    " see the full list

Real scenario

You edited a function at line 50, scrolled to line 300 to look at something, then jumped around reading context. Now you want to get back to where you were working. <C-o> takes you through every jump including all the reading you just did. g; takes you directly to line 50 — your last edit — in one or two keystrokes:

g;     " → line 50 (where you last edited)
g;     " → the edit before that, if any
g,     " → back to line 50

Caveat

The changelist is per-buffer and lives only as long as the buffer is open — unless you have :set undofile configured, in which case it's rebuilt from persistent undo history on next open. If you close a buffer and reopen without undofile, the changelist resets.

Wrap-up

These five commands don't get much screen time in tutorials, but they show up constantly in real editing sessions. \zs/\ze handle targeted substitutions without complex capture groups. :keeppattern keeps your search context intact while you do unrelated replacements. Recursive macros let you automate repetitive edits across a whole file without counting lines. The expression register turns Insert mode into a small calculator and templating engine. And g;/g, give you a direct path back to where you were actually working.

If you want more practical Vim tricks like these, I publish them at https://vimtricks.wiki.

What Vim action still feels slower than it should in your workflow?

Vim tricks I use when I need operations to land exactly right

Vimtricks.wiki — Fri, 13 Mar 2026 12:21:48 +0000

There's a category of Vim friction that isn't about speed — it's about landing in the right place. You recorded a macro that's almost right but has one wrong keystroke. You want to delete from here to a line you marked ten minutes ago. You're trying to insert newlines in a substitution and getting garbage characters instead. These aren't beginner problems, but they trip up experienced users too because the solutions aren't obvious.

Here are five tricks that consistently reduce that friction.

1) Edit a macro as plain text instead of re-recording it

Why it matters

Re-recording a long macro because of one wrong keystroke is painful. There's a faster way: paste the macro's keystrokes as editable text, fix the mistake, and yank it back.

"qp         " paste register q as text onto a new line
{edits}     " fix what's wrong using normal editing commands
0"qy$       " yank the corrected line back into register q
dd          " delete the helper line

Real scenario

You recorded a macro in q that processes log lines, but it uses w where it should use W. Type "qp to paste the raw keystrokes on a new line. The sequence appears as readable (and editable) text, including control characters rendered as ^[ for Escape and ^M for Enter. Fix the w, then 0"qy$ to yank the whole corrected line back into register q, then dd to clean up. Your macro is now corrected without re-recording a single keystroke.

Caveat

Non-printable keys appear as control characters. To insert them while editing, use <C-v> followed by the key — <C-v><Esc> inserts a literal escape byte. Typing a raw caret and bracket (^[) won't produce the right byte sequence and will break your macro in subtle ways.

2) Use a named mark as a motion target for operators

Why it matters

Named marks aren't just jump destinations — any operator (d, y, c, >, gq) accepts a mark as its motion target, giving you precise linewise ranges without entering visual mode.

ma          " set mark 'a' on the current line
{navigate}  " move somewhere else in the file
d'a         " delete from current line to the line containing mark a

Real scenario

You're cleaning up a config file. You set mark a at the start of a section you want to remove, scroll down to where it ends, and type d'a. The entire range — inclusive of both lines — is gone in one motion. The same trick works for yanking (y'a), re-indenting (>'a), or reformatting (gq'a). No visual mode, no line counting.

Caveat

The apostrophe form 'a is linewise — it operates on complete lines from the current line to mark a's line. If you need characterwise precision, use backtick: d`a deletes from the exact cursor position to the exact character where the mark was set. The two behave differently and it's easy to grab the wrong one, especially when the mark falls mid-line.

3) Anchor the second address of a range to the first match, not the cursor

Why it matters

In Vim range notation, a comma between two addresses makes the second address relative to the cursor. Replace it with a semicolon and the second address becomes relative to whatever line the first address matched — which is almost always what you actually want in scripts and macros.

:/error/;+2 yank a

Real scenario

You want to yank the next error log line plus the two lines after it, regardless of where your cursor is sitting. With /error/,+2 yank a, the +2 is relative to the cursor — if you're on line 1 and the error is on line 50, you capture lines 1–52 instead of 50–52. With /error/;+2 yank a, the +2 is anchored to the match at line 50, so you always get the right three-line block.

The semicolon form chains cleanly too: :/start/;/middle/;/end/ delete — each search anchors to the previous result rather than drifting back to the cursor.

Caveat

This distinction is easy to overlook in interactive use, but it matters a lot inside macros where cursor position is unpredictable. If range-based operations occasionally capture the wrong lines, a misused , vs ; is often the quiet culprit.

4) Use `\r`, not `\n`, to insert a newline in a substitution replacement

Why it matters

In a search pattern, \n correctly matches a newline. But in the replacement string, \n inserts a NUL byte (displayed as ^@) — not a line break. To insert an actual newline in the replacement, use \r.

:%s/,/\r/g

Real scenario

You have a comma-separated list on one line and want each item on its own line:

apple,banana,cherry

Running :%s/,/\n/g produces garbage characters. Running :%s/,/\r/g correctly splits it into three lines. Same deal when adding a blank line before every function declaration: :%s/^function/\r&/ works; :%s/^function/\n&/ silently inserts NULs.

Caveat

The asymmetry is consistent: \n in the search side matches a newline; \r in the replacement side inserts one. This is intentional in Vim's design, but it trips up nearly everyone at least once. In some Neovim builds \n in the replacement may happen to work, but \r is the portable and reliable choice across all Vim and Neovim versions.

5) Reuse the last substitution's replacement text with `~`

Why it matters

After a substitution, putting ~ in a new replacement string expands to whatever the last replacement was. This lets you apply the same transformation to a different pattern without retyping.

:%s/password/[REDACTED]/g
:s/api_secret/~/

Real scenario

You're sanitizing a config dump for a bug report. First you replace all occurrences of password with [REDACTED]. Then you spot api_secret a few lines down — same replacement needed. Instead of retyping the bracket-wrapped word, :s/api_secret/~/ expands ~ to [REDACTED] from the previous substitution. If you're normalizing a handful of different identifier patterns to the same replacement, you do the first one verbosely and all subsequent ones with ~/.

Caveat

~ expands to the most recent replacement text globally — if you run any other substitution in between, even on a different buffer, ~ picks up that replacement instead. Keep the sequence tight or verify the current ~ value before relying on it in a longer editing session.

Wrap-up

Five tricks that reduce the "close but not quite" friction in Vim work: editing a macro without re-recording it, using marks as operator motion targets, anchoring range endpoints with ;, inserting real newlines with \r in substitutions, and recycling replacement text with ~. None of these are obscure — they're just behaviors that pay off every few days once you know they exist.

If you want more practical Vim tricks, I publish them at https://vimtricks.wiki.
What Vim operation still feels more awkward than it should be?

Vim commands I use when precision editing matters

Vimtricks.wiki — Fri, 13 Mar 2026 12:16:53 +0000

Every Vim user builds a personal toolkit over time. The commands below are ones I kept bumping into — not in tutorials, but in the middle of actual work when the usual approach felt like one step too many. Each one solves a real friction point rather than just being clever for its own sake.

1) Recursive macros that stop themselves

Why it matters

When you record a macro to process N items, you usually need to know N in advance. Most people use a large count like 99@q and hope that's enough. A recursive macro is cleaner: it calls itself at the end of its body and stops automatically the moment any command in the sequence fails — no counting required.

qqq
qq{your commands}@qq
@q

The first line (qqq) clears register q so the embedded @q at the end of the recording is a harmless no-op rather than invoking a stale old macro. Then you record your macro and include @q as the final keystroke. Once recorded, @q starts the loop.

Real scenario

You have a list of lines where each one needs the first word removed. You don't know how many lines there are. Record qqdw0j@qq, then hit @q. The macro deletes the first word, moves to column 0, steps down one line, and recurses — until j fails on the last line and the whole chain stops.

Caveat

If the macro gets stuck in an infinite loop, <C-c> interrupts it. Also: if a command fails midway on a line rather than at the end of the file, the macro will stop early. Make sure your "stop condition" is the one thing that naturally fails when the work is done.

2) Pattern-relative offsets in Ex ranges

Why it matters

Ex command ranges usually use line numbers or marks, but Vim also lets you write ranges in terms of search patterns with numeric offsets. This means you can operate on "the three lines after the TODO comment" or "everything between two section markers" without knowing any line numbers at all.

:/pattern/+N,/other-pattern/-N delete

The /pattern/+1 form says "the line one below the next match of this pattern." The -1 form says "the line one above." You can use these addresses with any Ex command that takes a range: :delete, :yank, :move, :copy, :substitute, :normal, and so on.

Real scenario

A config file has sections delimited by # BEGIN and # END comments, and you need to delete everything between them (not including the markers themselves):

:/# BEGIN/+1,/# END/-1delete

That's a complete command. No line number lookup, no visual selection. Works regardless of where in the file the block lives.

Caveat

If the search pattern doesn't exist in the buffer, Vim will error out. When scripting this kind of range, wrap the command in :silent! or guard with a pattern check first. Also remember that /pattern/ searches forward from the cursor — position matters when a pattern appears multiple times.

3) Opening the command-line window mid-command

Why it matters

Vim's command-line window (q: from Normal mode) is great for editing and re-running previous commands. Less known is that you can open it while you're already typing a command — press <C-f> in the middle of your :s substitution and Vim drops you into the command-line window with your half-typed command loaded and ready for full Vim editing.

<C-f>   (press while in : / ? mode)

This works from any command-line mode: :, /, ?, or !. The in-progress command appears at the bottom of the window, and you can use any Normal-mode motions to fix it before pressing <CR> to execute.

Real scenario

You're typing a complicated substitution:

:%s/\v(class|module)\s+\zs\w+/

You realize you got the regex wrong two groups back. Instead of <C-b> and arrow keys, press <C-f>. The command opens in an editable buffer. Use F( to jump to the paren, ci( to fix it, then <CR> on the line to run it.

Caveat

q: from Normal mode also opens the command-line window, but it only shows history — it cannot capture what you were currently typing. <C-f> is specifically for the mid-input case. Close the window without running with :q or <C-c>.

4) The `'^` mark: return to the last insert position

Why it matters

Vim automatically updates the ^ mark every time you leave Insert mode. Pressing '^ in Normal mode jumps back to the exact position where your cursor was when you hit <Esc>. Unlike gi — which jumps there and immediately re-enters Insert mode — '^ is a plain mark jump: you arrive, look around, and decide when to start editing again.

'^

Real scenario

You're editing a function, escape out to check a related block above, then use /search or % to explore a bit. When you're ready to return, '^ brings you straight back to column and line — no searching, no <C-o> chain. Then press a or i when you're actually ready to type.

Caveat

If gi already fits your workflow — jump back and start typing — there's no reason to switch. '^ is the right choice when you want to inspect the position first, or when you want to use an operator there rather than enter Insert mode. The mark is also buffer-global: if you switched files, '^ will switch back to the other buffer.

5) `gP` — paste before the cursor, land after it

Why it matters

The standard P pastes text before the cursor and leaves the cursor sitting on the first character of what was just inserted. gP pastes in the same position but moves the cursor to after the inserted text. That might sound minor, but when you're assembling content from multiple pastes or continuing to type immediately after, it eliminates the manual $ or e move you'd otherwise need.

gP

The lowercase gp is the after-cursor equivalent of p — same behavior, cursor ends up after the paste.

Real scenario

You're building a line by pasting three named registers in sequence. With "agP"bgP"cgP, each paste leaves your cursor positioned for the next, and you end up after all three pieces without touching a motion key in between.

Caveat

gP with a count (3gP) pastes three copies in a row and leaves the cursor after all three, not after just the first. This is intentional and usually what you want, but it's worth knowing before you use it inside a macro.

Wrap-up

These five commands live in different areas of Vim — macros, Ex ranges, command-line editing, marks, and paste operations — but they share a common thread: each one removes a step that you'd otherwise do manually. Recursive macros eliminate counting. Pattern offsets eliminate line number lookups. <C-f> eliminates awkward command-line navigation. '^ eliminates refinding your position. gP eliminates cursor repositioning after paste.

If you want more practical Vim tricks explained at this level, I publish them at https://vimtricks.wiki.

What Vim workflow still has a step you wish you could skip?

Vim commands that handle the detail work without friction

Vimtricks.wiki — Mon, 02 Mar 2026 12:45:35 +0000

Most of the time Vim does what you expect. But there is a category of editing tasks where the obvious approach quietly fails you: numeric data that sorts wrong, a diff window you can only scroll through, a macro that breaks because of your own mappings, or a regex that swallows half the file instead of a small piece of it. None of these are exotic edge cases — they come up in ordinary work.

These five commands are the ones I reach for when that category of problem shows up.

1) Jumping between diff hunks without scrolling

Why it matters

When you open two files side by side with vimdiff or :diffsplit, the changed sections are highlighted — but you still have to find them. Scrolling through a large file looking for the next colored block is slow and easy to miss. ]c and [c are motions that jump directly to diff hunks, skipping unchanged content entirely.

]c   " jump forward to the next changed hunk
[c   " jump backward to the previous changed hunk

Real scenario

You are reviewing a pull request locally with vimdiff old.go new.go. The files are 300 lines each and there are seven changes scattered through them. Pressing ]c from the top takes you directly to each hunk in sequence. Pressing [c steps back if you want to re-examine one. No scrolling.

Caveat

These motions require an active diff session — they do nothing in a regular buffer. If you land on a hunk and want to act on it, do (diff obtain) pulls the change from the other window, and dp (diff put) pushes it the other direction. Run :diffupdate if the highlighting goes stale after you make edits.

2) Sorting lines numerically instead of lexicographically

Why it matters

Plain :sort in Vim is alphabetical. That means 10 sorts before 2, 100 sorts before 9, and a list of version numbers or file sizes ends up in nonsensical order. Adding the n flag tells Vim to compare lines by numeric value instead of character code.

:'<,'>sort n    " sort selected lines numerically, ascending
:'<,'>sort n!   " sort numerically, descending
:%sort n        " sort the whole buffer numerically

Real scenario

You have a list of benchmark results:

150ms  parse_config
23ms   load_cache
1200ms run_query
87ms   render_view

Selecting all four lines and running :'<,'>sort n orders them by the leading number: 23ms, 87ms, 150ms, 1200ms. With plain sort, you get 1200ms second because "1" < "8" lexicographically.

Caveat

The n flag extracts the first integer found on each line as the sort key. If a line has no leading number, Vim treats it as zero. Non-numeric lines that happen to mix in will group at the top. For floating-point values or sorting by a middle column, pipe through an external sort instead: :'<,'>!sort -k1 -n.

3) Running normal mode commands without your mappings interfering

Why it matters

:normal {cmd} is a powerful way to replay Normal mode keystrokes over a range of lines — common in macros, autocommands, and shared vimrc snippets. The problem is that it applies your custom mappings. If you have nnoremap w b in your config, then :%normal w moves backward instead of forward. Adding a bang fixes it: :normal! {cmd} always executes the built-in command, regardless of what you have mapped.

:%norm! A;       " append semicolon to every line using the real A, not any remapped A
:'<,'>norm! >>   " indent selected lines using the real >>, not any remapping
:5,10norm! dw    " delete first word on lines 5–10 using the real dw

Real scenario

You are writing a function in a shared vimrc that bulk-indents a range of lines. Without the bang, the function breaks on any machine where > has been remapped. With :norm!, the function works identically everywhere, regardless of the user's mapping configuration.

Caveat

:norm! does not accept special key notation directly in command-line usage. If your command needs <CR>, <Esc>, or <C-a>, you have to wrap it in :execute "norm! \<CR>" (using execute to interpolate the special key). This applies to any key that requires angle-bracket notation.

4) Reverting to the last saved state in one step

Why it matters

Vim's undo history is deep and time-stamped. The :earlier command navigates it using time units instead of individual undo steps — and f is the unit for file writes. So :earlier 1f jumps the buffer back to exactly the state it was in when you last ran :w. It does not matter if you made 50 changes since then; one command reverts all of them.

:earlier 1f     " revert to state at last file write
:earlier 2f     " revert to two saves ago
:later 1f       " re-apply forward to next write checkpoint

Real scenario

You refactored a function, saved, continued editing, and an hour later realized the refactor introduced a subtle bug. You want to see the version just before that last batch of changes without destroying the ability to redo. :earlier 1f takes you back to the previous save in one command. If you change your mind, :later 1f restores the current state.

Caveat

This uses Vim's in-memory undo tree — it does not reload the file from disk. If you want a true disk reload, use :e! instead. Also, undo history is lost when you close Vim unless you have :set undofile enabled. With undofile, the undo tree persists across sessions, which makes :earlier 1f useful even after restarting Vim.

5) Matching the shortest possible string in a regex

Why it matters

By default, .* in a Vim pattern is greedy — it matches as many characters as possible. When your text has repeated delimiters, that means one .* can consume far more than you intended, from the first delimiter all the way to the last one in the file. Vim's non-greedy quantifier is \{-}, and it works as the lazy counterpart to *, matching as few characters as possible.

/start.\{-}end        " matches shortest span from 'start' to 'end'
:%s/<b>.\{-}<\/b>//g  " removes each <b>...</b> tag pair individually

Real scenario

You have a log file with repeated bracketed fields:

[INFO] Request received [user=alice] [status=200]
[WARN] Timeout reached [user=bob] [status=408]

Running :%s/\[.\{-}\]//g removes every bracket pair individually. Using greedy .* instead would eat from the first [ all the way to the last ] on the line, deleting content you wanted to keep.

Caveat

\{-} is Vim's regex syntax, not PCRE. If you are accustomed to .*? from Python or JavaScript, this is the direct equivalent but the syntax is different. In Vim's very-magic mode (\v), you can write {-} without the backslash. For zero-or-more non-greedy, use .\{-}. For one-or-more, use .\{-1,}.

Wrap-up

None of these are obscure. Diff navigation with ]c/[c replaces scrolling. Numeric sort with sort n prevents the kind of ordering bug that looks like a data problem until you realize it is not. :norm! is essential the moment you start writing any vimrc automation. :earlier 1f is a safety net for the editing session. And non-greedy \{-} is one of those regex tools you reach for constantly once you know it exists.

If you want more practical Vim tricks like these, I publish them regularly at https://vimtricks.wiki.

Which of these do you already use, and which ones sneak up on you?

Switching between files in Vim without fuzzy-finding everything

Vimtricks.wiki — Wed, 25 Feb 2026 07:37:24 +0000

Most of the time, fuzzy-finding isn't what you need. You already know which file you want — you were just there. The real problem is getting back to it fast.

Here's a progression from the fastest built-ins to a full fuzzy picker, ordered by how much setup each requires.

1) `<C-^>` — toggle the file you were just in

If you're jumping between exactly two files — say, auth.go and auth_test.go — this is the only command you need.

<C-^>

Why it matters

<C-^> switches to the alternate file, which is simply the last buffer you had open. No filename to type, no fuzzy search, no menu. Just one keystroke back where you were.

Real scenario

You jump to a test file with gd to look up an interface definition. You've read what you need. <C-^> lands you back at your implementation file, cursor exactly where you left it.

Caveat

This only remembers one previous file. The moment you open a third buffer, the earlier one is no longer the alternate. For two-file back-and-forth it's unbeatable; for broader navigation you need something else.

2) Global marks (`mA`, `'A`) — pin files you return to constantly

When you have 2-3 files you keep coming back to during a session — config, main handler, test file — global marks let you warp there instantly.

" Set a global mark (uppercase letter = global, persists across files)
mA

" Jump to it from anywhere
'A

Why it matters

Lowercase marks (ma, 'a) are local to the buffer. Uppercase marks (mA, 'A) are global — they remember both the file and line number. Press 'A from anywhere in Vim and you jump directly to that exact line in that file.

Real scenario

You're working on a feature and constantly need to reference routes.go. Press mR once on the relevant line. For the rest of the session, 'R gets you there in one keystroke from any file.

Caveat

Global marks are persistent across Vim sessions (written to ~/.viminfo or ~/.local/share/nvim/shada/main.shada). That's useful but also means stale marks from last week can send you to the wrong place. Clean them up occasionally with :delmarks A-Z.

3) `<C-o>` / `<C-i>` — retrace your navigation history

When you've been jumping around a codebase following references — gd to definition, then another gd, then a search — <C-o> walks you back through the full path.

<C-o>   " jump back (older position in jump list)
<C-i>   " jump forward (newer position)

Why it matters

Vim keeps a jump list — a history of every position you've jumped to (via gd, gg, /pattern<CR>, 'mark, etc.). <C-o> steps backward through that history, including across files. It's like a browser back button for your editing session.

Real scenario

You press gd to follow a function call into a helper, then follow another reference deeper. After reading the implementation, <C-o><C-o> brings you back through the call chain to where you started — no need to remember file names or line numbers.

Caveat

The jump list tracks positions, not intent. If you've been jumping around a lot, <C-o> might take you through more stops than expected before landing where you wanted. Use :jumps to see the full list and get your bearings.

4) Native buffer commands — `:b partial<Tab>`, `]b`/`[b`, `:ls`

Before reaching for plugins, the built-in buffer commands cover most cases.

:ls          " list all open buffers with numbers and names
:b partial   " switch to buffer by partial filename match
:b 3         " switch to buffer number 3
]b           " next buffer (vim-unimpaired or manual mapping)
[b           " previous buffer

Why it matters

:b partial<Tab> tab-completes buffer names, so typing :b auth<Tab> switches to auth.go without typing the full name. :ls gives you a quick overview when you're not sure what's open. ]b/[b are useful when you want to cycle through a small number of buffers sequentially.

Real scenario

You remember you had some migration file open but can't remember the full name. :b migr<Tab> completes to 2024_add_users_migration.sql — done.

Caveat

:b partial matches against the full path, not just the filename. If you have two files with similar paths, the completion might behave unexpectedly. Use :ls first to check what's open and note the buffer numbers.

5) `wildmode=lastused` + `wildcharm` — a Tab-completion buffer picker

With two config lines, you can turn :b <Tab> into a fast MRU-ordered buffer picker, and then bind it to a single keypress.

set wildmenu
set wildmode=lastused
set wildcharm=<Tab>
nnoremap <leader>b :b <Tab>

Why it matters

wildmode=lastused reorders buffer completions so the most recently used buffers appear first. wildcharm=<Tab> is the less-known piece: it tells Vim which key triggers wildmenu expansion inside mappings (Tab doesn't work in mappings by default). Together, <leader>b drops you into a visual buffer list ordered by recency.

Real scenario

You've been alternating between four files all morning. Press <leader>b and the wildmenu immediately shows the last file you had open — one more <Tab> for the one before that. No plugin needed.

Caveat

wildmode=lastused is available in Vim 9.1+ and modern Neovim. Older Vim installations won't have it — check :help 'wildmode' and look for the lastused entry.

6) Harpoon — a persistent pinned-file list

If you work on the same 4-5 files across multiple sessions, Harpoon gives you numbered slots that survive restarts.

" Add current file to Harpoon list
:lua require('harpoon.mark').add_file()

" Open the Harpoon menu
:lua require('harpoon.ui').toggle_quick_menu()

" Jump directly to slot 1-4
<leader>1  <leader>2  <leader>3  <leader>4

Why it matters

Global marks are session-persistent but limited to 26 slots and tied to specific line numbers. Harpoon gives you a small, curated list of files you're actively working on — the 4-6 files that matter for this task — and lets you jump between them with numbered shortcuts that stay the same all day.

Real scenario

You're implementing a feature that touches handler.go, service.go, service_test.go, and schema.sql. Mark all four in Harpoon at the start of the day. Now <leader>1 through <leader>4 get you to each one instantly, no matter how many other buffers you open in between.

Caveat

Harpoon is Neovim-only and requires Lua configuration. The list is project-aware (scoped to the git root), which is useful but means you maintain separate lists per project. It's intentionally minimal — if you want fuzzy search over the pinned files, you'll need Telescope integration.

7) `:Telescope buffers` — fuzzy search over all open buffers

When you have many buffers open and don't remember enough of the filename to use :b partial, the Telescope buffer picker lets you fuzzy-search everything.

:Telescope buffers

" Recommended binding:
nnoremap <leader>fb <cmd>Telescope buffers<CR>

Why it matters

The Telescope buffer picker shows all open buffers with their numbers and modification state ([+] for unsaved changes). Type any substring to filter in real time. <C-d> deletes a buffer from the list without leaving the picker — useful for trimming stale buffers during a long session.

Real scenario

You've been working for three hours and have 15 buffers open. You need to get back to a migration file but can't remember the exact name. Type migr in the picker and it narrows immediately to the one you want.

Caveat

Neovim only. If you're on vanilla Vim, fzf.vim's :Buffers command gives you essentially the same picker. Neither requires you to know buffer numbers — just type enough of the name and pick.

Wrap-up

These techniques stack. In practice: <C-^> for the last file, 'A/'B for pinned files you visit constantly, <C-o> to retrace after diving into definitions, <leader>b for a quick MRU-ordered list when you have a few buffers open, and :Telescope buffers when you need to search across many.

The sweet spot for most people is <C-^> + global marks + wildmode=lastused — zero plugins, huge improvement over default behavior.

If you want more of this, the full explanations are on vimtricks.wiki. What file-switching workflow are you currently using that still feels clunky?

My first post on dev.to

Vimtricks.wiki — Tue, 24 Feb 2026 08:51:17 +0000

How I handle bulk text changes in Vim

Vimtricks.wiki ・ Feb 24

#vim #neovim #productivity #programming

How I handle bulk text changes in Vim

Vimtricks.wiki — Tue, 24 Feb 2026 08:35:02 +0000

Most of the time when editing gets tedious, it's not one hard change — it's fifty copies of the same small change, or a block of generated content that shouldn't be there, or inconsistent casing across identifiers. Vim has dedicated commands for each of these situations, but they're easy to miss if you learned the basics and stopped there.

Here are five commands I reach for when text cleanup turns mechanical.

1) Pass the whole buffer through an external tool

Why it matters

Vim's ! operator sends text through a shell command and replaces it with the output. :%! does this for the entire buffer. You don't need a plugin or a formatter wired into your editor — if the tool runs from a shell, it works here.

:%!jq .

Real scenario

You're looking at a one-line JSON response pasted from a terminal. Instead of copying it to an online formatter, run :%!jq . and the buffer is instantly readable. Same idea for :%!sort -u to deduplicate a list, or :%!column -t to align a table of values.

For a subset of lines, use a range: :5,20!indent formats only those lines. Visual selection followed by ! auto-fills :'<,'> for you.

Caveat

If the command exits nonzero or writes nothing to stdout, Vim restores the original buffer — so it's safe to experiment. But if the tool crashes midway and writes partial output, you'll need u to undo. Check the result before saving.

2) Transform case directly inside a substitute

Why it matters

Vim's replacement string supports case-transform atoms: \U uppercases everything that follows, \L lowercases it, \u and \l affect only the next character. Combined with capture groups, this handles identifier normalization that would otherwise need a separate script.

:%s/\v<(\w+)>/\u\L\1/g

Real scenario

You have a config file where environment variable names are inconsistently cased — some SCREAMING_SNAKE, some screaming_snake, some mixed. A single :%s/\v(\w+)/\U\1/g uppercases all of them in one pass. Or you're converting a list of snake_case keys to Title Case for a document: :%s/_$\w$/\u\1/g capitalizes after every underscore.

Caveat

\U and \L affect the rest of the replacement string, not just the next character. If you write \U\1-\2, both capture groups get uppercased. Use \E to end the transform explicitly: \U\1\E-\2 uppercases only \1 and leaves \2 unchanged.

3) Navigate through matches while still typing the search

Why it matters

With incsearch active (the default in Vim 8+ and Neovim), <C-g> and <C-t> jump forward and backward through matches while you're still in the search prompt. You can see exactly which occurrence you'll land on before pressing Enter — no committing to a search and then recounting with n.

/config<C-g><C-g>

Real scenario

A file has thirty references to user and you want the third occurrence in a specific function. Type /user, press <C-g> twice to skip past the first two matches, then confirm with <CR>. It beats a blind search followed by n presses, especially when matches are spread across hundreds of lines.

Caveat

This only works with :set incsearch, which is on by default in modern Vim/Neovim but may be absent in minimal or legacy configs. Also note that <C-g> in normal mode shows file info — this shortcut is search-prompt-only, so don't confuse the two.

4) Delete structured blocks between two pattern markers

Why it matters

:g (global) accepts a range, not just individual line targets. :g/start/,/end/d matches every line containing start, extends the range to the next line containing end, and deletes the whole block — both markers and everything between them.

:g/<!-- BEGIN GENERATED -->/,/<!-- END GENERATED -->/d

Real scenario

A template generates HTML with clearly marked scaffolding sections. Before committing, you want those blocks stripped from the output. One command removes every matching block in the file, no matter how many there are. The same pattern cleans up log files: :g/DEBUG START/,/DEBUG END/d removes every debug dump in a crash log you're trying to read.

Before previewing what would be removed, run:

:g/<!-- BEGIN GENERATED -->/,/<!-- END GENERATED -->/p

Caveat

:g processes matches top to bottom and adjusts line numbers as it goes, so back-to-back blocks are handled correctly. However, if an end marker appears before its corresponding start marker (malformed blocks), the range will expand into unintended territory. Preview with :p before running d.

5) Run a command at every quickfix entry

Why it matters

:cdo {cmd} executes a command at each entry in the quickfix list. Unlike :cfdo (once per file), :cdo visits each individual match location — useful when you want per-occurrence precision rather than a blanket file-wide substitution.

:vimgrep /deprecatedCall/ **/*.go
:cdo s/deprecatedCall/replacementCall/ | update

Real scenario

You're retiring a function. Grep populates the quickfix list with every call site across the project. :cdo substitutes at each location and saves the file. Two commands, no manual file-opening. You can also use :cdo norm @q to replay a recorded macro at each entry — handy when the change is structural and context-dependent enough that a regex won't cut it.

Caveat

:cdo runs at every quickfix entry, including duplicate lines if the same line appears in multiple results. Use :cfdo instead if you'd rather operate once per file. Also, :cdo doesn't save files by default — always append | update unless you want to review diffs before writing.

Wrap-up

These five commands cover a lot of ground: piping through external formatters, case transforms inside substitutions, navigating matches interactively, deleting structured blocks, and project-wide refactoring from the quickfix list. None require plugins and all work identically in Neovim.

If you want more practical Vim tricks like these, I publish them at https://vimtricks.wiki.

What bulk editing task in Vim still feels slower than it should?