Vim vs VS Code: the same editing tasks, side by side

23 tasks · 19 with a documented equivalent in both · updated 2026-10-07

Vim and VS Code are not two keymaps for the same model of editing; they are two models. Vim's keys are single letters that only mean something in normal mode (dd deletes a line because d is the delete operator and the second d means 'this line'), while VS Code's are chorded shortcuts that work regardless of state. The table pairs the same task in both so that someone moving between them, or running the Vim extension inside VS Code, can see where the keys differ and where one editor simply has no single-key equivalent.

Gaps in the table mean that editor's reference page has no row for the task: the Vim page has no comment toggle, and the VS Code page has no key for joining lines and nothing for Vim's repeat (.) or macros (q{a-z} / @{a-z}). Vim's replace is typed as an :s command, where VS Code opens its Find widget with the replace field. The VS Code column gives the Windows keys; the VS Code page lists the Mac ones beside them. The Vim movement keys h j k l and the text objects (iw, i" and the others on the Vim page) have no matching rows in the VS Code table.

If you use both through the VSCodeVim extension, its README says the extension takes over the control keys in the editor the way Vim does (VS Code's Ctrl + F find, for example) and that its useCtrlKeys and handleKeys settings hand chosen keys back to VS Code. The full tables on each tool's page list the rest, including Vim's visual modes and VS Code's multi-cursor, debugging and panel shortcuts.

Full references: Vim (202) · VS Code (197) · all comparisons

How to use the table

Read a row as "the task, then each editor's way of doing it", and expect the Vim column to be shorter: a Vim entry such as ciw is three keystrokes that combine an operator and a text object, while the VS Code entry is one chord. Where the Vim column shows a command-line entry (:%s/…), it is a different mode again. Rows with a dash in one column mean that editor's reference page has no such row — the VS Code page lists no dot-repeat or macro keys, the Vim page no comment toggle — and those rows are the ones to read when deciding whether to install the Vim extension in VS Code or to learn VS Code's own multi-cursor model instead.

Which to learn

If you already know one, the table is a translation aid; if you know neither, start with VS Code's keys and add the Vim extension later, because a Vim extension brings Vim's operators, motions and text objects into VS Code and lets the two models coexist. The full references for each editor are linked at the top, and the Vim page on this site explains the operator-plus-motion grammar that makes the Vim column make sense.