Vim Language, Motions, and Modes Explained (2023)

Vim vs VS Code and IDEs

  • Some see Vim as obsolete next to VS Code’s “modern car” feature set; others describe VS Code as bloated, slow, telemetry-laden, and less configurable, with Vim as the “sports car.”
  • Disagreement over “once configured”: one side says VS Code can do everything Vim can plus more; the other replies that “once configured” applies equally to Vim/Neovim with their rich plugin ecosystems.
  • Several argue editor wars are pointless: different tools fit different minds and workflows.

Modal Editing, Vim “Language,” and How You Think

  • Many praise the composable “verb + motion + text object” model (e.g., ci(, ct&) as uniquely elegant and mentally satisfying.
  • Some claim mode switching imposes heavy overhead, especially for people who constantly tweak small parts of text; others report it becomes unconscious muscle memory where i...<Esc> is perceived as a single action.
  • A recurring idea: Vim changes how you think about editing—treating the editor as a programmable language with macros, registers, and structural navigation.

Efficiency, Productivity, and What Really Matters

  • Multiple comments stress Vim doesn’t make you inherently “better” than others; most engineering time isn’t text manipulation.
  • Vim is framed less as “speed” and more as reduced effort, precision, and flow; critics counter that great engineers using mice, nano, or IDEs can still massively outperform.
  • Consensus: navigation speed helps, but core engineering skills (problem solving, communication, knowledge management) are more decisive.

Ergonomics and RSI

  • Several report Vim (and less chord-heavy workflows) curing or greatly reducing RSI compared to Emacs-style multi-modifier key chords or heavy mouse use.
  • Vim plus tiling window managers reduces mouse/keyboard shuttling; others adapt keyboard layouts (e.g., Caps Lock → Esc, or US layout for code).

Learning Curve, Discoverability, and Keybindings

  • Vim is widely acknowledged as non-intuitive and not self-teaching; mastery is compared to learning a musical instrument.
  • Discoverability is a pain point: many users only learn features by targeted searching, not by exploration.
  • Some hesitate to rebind keys because they value being able to sit down at any machine and use “stock” Vim; others argue customization is normal and expected.
  • Layout issues (Colemak/Dvorak, non‑US keyboards) make default motions feel awkward; opinions differ on how much of a barrier this is.

Helix, Kakoune, and Motion–Action vs Action–Motion

  • Helix and Kakoune’s “motion then action” model is seen by some as more intuitive (select first, then operate), with better built-in discoverability and modern LSP/Tree‑sitter support.
  • Others find motion–action editors mentally unstable: navigation leaves behind selections/multi‑cursors and feels like the editor is “waiting” for an action, breaking the simple “move, then edit” rhythm of Vim.
  • Debate over which paradigm is optimized for small local edits vs large structural refactors; some argue motion–action overemphasizes “editing in the large.”

Universality, Terminals, and Minimalism

  • A strong appeal of Vim is that it “just opens” without nags, runs in terminals/SSH, and is available on almost every Unix-like system.
  • This universality drives people to seek Vim keybindings even inside heavy IDEs and note-taking apps.
  • Some see modern IDEs’ constant prompts, setup rituals, and GUI friction as a regression compared to Vim’s quiet, scriptable environment.

Macros, Regex, and Power Workflows

  • Several anecdotes highlight Vim macros + regex as extremely powerful for bulk log/data cleanup and structural text transforms, often faster than GUI find/replace.
  • Others note that language models can now perform some of these transformations, albeit with verification overhead.

Culture and “Worse Is Better”

  • One thread frames Vim as a “right thing” tool in a landscape of “worse is better” IDEs that prioritize quick onboarding over deep mastery.
  • There’s concern about technical monocultures (e.g., VS Code dominance); diversity of tools (including Vim holdouts) is seen as cultural and intellectual insurance.