Project 7: The Vim Golf Challenge

Minimize keystrokes by expressing edits as the shortest possible Vim sentences.

Quick Reference

Attribute Value
Difficulty Level 4: Expert
Time Estimate Ongoing (weekly practice)
Main Programming Language None (text editing)
Alternative Programming Languages Any
Coolness Level Level 4: Expert efficiency
Business Potential 2: Speed cult
Prerequisites Strong motions, operators, dot repeat
Key Topics Keystroke economy, operators, counts, dot

1. Learning Objectives

By completing this project, you will:

  1. Reduce multi-step edits into the shortest operator+motion sequences.
  2. Use counts and text objects to eliminate unnecessary keystrokes.
  3. Identify when Visual mode is slower than operator grammar.
  4. Develop a mental habit of “edit design” before typing.
  5. Build a personal catalog of minimal solutions.

2. All Theory Needed (Per-Concept Breakdown)

2.1 Keystroke Economy and Operator Grammar

Fundamentals

Vim golf is about expressing an edit with the fewest keystrokes. The secret is the operator+motion grammar: a verb (operator) and a noun (motion/text object). When you can express a target with a single motion, you avoid extra mode switches or cursor moves. This means you should always ask: “Can I replace a sequence of moves with a single motion or text object?”

Deep Dive into the concept

The operator grammar is compositional: d + w deletes a word; gU + w uppercases a word. When you recognize the smallest motion that covers your target, you reduce keystrokes. In Vim golf, the goal is not just speed but precision: fewer keystrokes mean fewer opportunities for error. The deeper skill is learning the available motions and operators so you can choose the one that expresses the entire intent.

How this fits on projects

  • You will turn verbose edits into one-line Vim sentences.
  • You will compare multiple solutions and choose the shortest.

Definitions & key terms

  • Operator: Verb that changes text (d, c, gU).
  • Motion: Noun that selects text (w, }, f,).
  • Keystroke economy: Minimizing the number of keys for an edit.

Mental model diagram (ASCII)

Intent -> operator + motion -> shortest edit

Intent to minimal edit

How it works (step-by-step)

  1. Describe the edit in words.
  2. Identify the smallest target motion.
  3. Apply the operator to that motion.
  4. Compare against a longer approach.

Minimal concrete example

gU$A!<Esc>    " uppercase line and add !

Common misconceptions

  • “Golf is only about speed”: It is about clarity and precision.
  • “Visual mode is always faster”: Often it adds unnecessary keystrokes.
  • “Counts are optional”: Counts often reduce multiple steps to one.

Check-your-understanding questions

  1. Why is gU$ shorter than v$gU?
  2. What does 3w replace?
  3. How do you uppercase a word without visual mode?

Check-your-understanding answers

  1. It avoids entering Visual mode.
  2. It replaces www with a single command.
  3. Use gUiw.

Real-world applications

  • Making quick edits during pair programming.
  • Efficient text transformations in code reviews.

Where you’ll apply it

  • See Section 3.4 Example Usage / Output and Section 5.10 Implementation Phases in this project.
  • Also used in: Project 1: No-HJKL Navigator.

References

  • “Practical Vim” Ch. 1, 5

Key insights

If you can name the target, you can minimize the keystrokes.

Summary

Keystroke economy is about expressing the edit as a single, composable Vim sentence.

Homework/Exercises to practice the concept

  1. Find a shorter alternative to v$gU.
  2. Reduce dw + i into one change.

Solutions to the homework/exercises

  1. Use gU$.
  2. Use cw.

2.2 Dot Repeat and Edit Normalization

Fundamentals

Dot repeat (.) is a keystroke multiplier. If you can make one clean, atomic change, you can repeat it across multiple targets. In Vim golf, this means you should design the first edit so it is reusable. This often yields the shortest overall sequence across multiple edits.

Deep Dive into the concept

Not all edits are repeatable. If you perform a sequence of commands that includes multiple changes, . will only repeat the last one. This is why “edit normalization” matters: you want each change to be a single command. For example, using cw instead of dw followed by i creates an atomic change that . can repeat. The deeper skill is recognizing which part of the edit should be the change, and which part should be the navigation.

How this fits on projects

  • You will design at least one edit that repeats across multiple lines.
  • You will compare solutions with and without dot repeat.

Definitions & key terms

  • Dot repeat: Repeats the last change command.
  • Atomic change: A single command that performs a full edit.
  • Normalization: Designing an edit so it is repeatable.

Mental model diagram (ASCII)

One clean edit -> . -> . -> .

Dot repeat flow

How it works (step-by-step)

  1. Make a single atomic change.
  2. Move to the next target.
  3. Press . to repeat.
  4. Evaluate total keystrokes saved.

Minimal concrete example

cw new<Esc>
 n .

Common misconceptions

  • “Dot repeats movement”: It repeats only the change.
  • “Dot repeat is unreliable”: It is reliable when the change is atomic.
  • “Repeatability is optional”: It often yields the shortest solution.

Check-your-understanding questions

  1. Why is cw more repeatable than dw then i?
  2. What does . repeat after A!<Esc>?
  3. How do you combine n and .?

Check-your-understanding answers

  1. cw is a single change command.
  2. It repeats the append and insertion of !.
  3. Use /pattern, edit once, then n ..

Real-world applications

  • Applying the same fix across multiple lines.
  • Batch changes in logs or configs.

Where you’ll apply it

  • See Section 5.8 Hints in Layers and Section 6 Testing Strategy in this project.
  • Also used in: Project 3: Code Refactor.

References

  • “Practical Vim” Ch. 1

Key insights

The shortest solution often includes dot repeat.

Summary

Dot repeat turns a single good edit into a sequence. It is essential for both Vim golf and real-world editing.

Homework/Exercises to practice the concept

  1. Fix a repeated typo in five lines using n ..
  2. Change a suffix on three lines using A and ..

Solutions to the homework/exercises

  1. /typo, cw fix<Esc>, then n ..
  2. A_suffix<Esc>, then j ..

2.3 Lesser-Known Operators and Motions

Fundamentals

Vim has operators that are often overlooked but reduce keystrokes: gU for uppercase, gu for lowercase, ~ for toggle case, and g~ for case toggling across a motion. Motions like F, T, and % can also reduce steps. Learning these gives you more options to find the shortest path.

Deep Dive into the concept

The difference between gU and gu is case direction, and ~ toggles case at the cursor. These operators can be combined with motions and text objects (gUiw, gU$). The deeper skill is remembering the operator when it reduces a multi-step process. For example, uppercasing a word with gUiw is shorter than viwU.

How this fits on projects

  • You will solve golf challenges using case operators and uncommon motions.
  • You will compare solutions with and without these operators.

Definitions & key terms

  • Case operator: gU, gu, g~, ~.
  • Percent motion (%): Jump to matching bracket/brace.
  • Reverse find: F and T search backward on a line.

Mental model diagram (ASCII)

gU + iw -> uppercase word
% -> jump between matching braces

Vim golf primitives

How it works (step-by-step)

  1. Identify a transformation (case, match jump).
  2. Choose the operator or motion that covers it.
  3. Apply with a text object for minimal keystrokes.

Minimal concrete example

gUiw    " uppercase word
%       " jump to matching brace

Common misconceptions

  • “Case changes require Visual mode”: Operators do it faster.
  • ”% is only for parentheses”: It works on many matching pairs.
  • “Reverse find is rare”: It is useful on long lines.

Check-your-understanding questions

  1. What does gUiw do?
  2. How do you toggle case of a word?
  3. What does % do on a bracket?

Check-your-understanding answers

  1. Uppercases the inner word.
  2. Use g~iw or ~ repeatedly.
  3. Jumps to the matching bracket.

Real-world applications

  • Quick casing fixes in identifiers.
  • Navigating nested code blocks.

Where you’ll apply it

  • See Section 3.4 Example Usage / Output and Section 5.10 Implementation Phases in this project.
  • Also used in: Project 6: HTML Tag Wrapper.

References

  • :help gU
  • :help %

Key insights

The shortest command is often a less common operator.

Summary

Knowing a handful of lesser-known operators unlocks shorter solutions and expands your Vim vocabulary.

Homework/Exercises to practice the concept

  1. Uppercase three words using gU3w.
  2. Use % to jump between matching braces in code.

Solutions to the homework/exercises

  1. gU3w.
  2. Place cursor on { then press %.

3. Project Specification

3.1 What You Will Build

You will solve a set of Vim golf challenges and document the minimal keystroke solutions. The deliverable is a challenge list, solutions, and keystroke counts.

3.2 Functional Requirements

  1. Challenge Set: Define at least 10 text-editing challenges.
  2. Minimal Solution: Provide a Vim command sequence for each.
  3. Keystroke Count: Record the number of keystrokes.
  4. Alternatives: Provide at least one alternative solution for comparison.

3.3 Non-Functional Requirements

  • Clarity: Solutions must be reproducible.
  • Repeatability: Solutions should not rely on external tools.
  • Honesty: Keystroke count should include all keys.

3.4 Example Usage / Output

Challenge: Change "teh" to "the"
Solution: xp
Keystrokes: 2
Alternative: cw the<Esc>

3.5 Data Formats / Schemas / Protocols

Use a Markdown table for challenge tracking:

| Challenge | Solution | Keys |
|-----------|----------|------|
| teh->the  | xp       | 2    |

p07_golf_table

Vim golf table

3.6 Edge Cases

  • Multiple valid minimal solutions.
  • Solutions that depend on cursor position.
  • Ambiguous keystroke counts (counts vs repeated keys).

3.7 Real World Outcome

You will have a personal Vim golf catalog that improves your daily editing speed.

3.7.1 How to Run (Copy/Paste)

vim vim_golf.md

3.7.2 Golden Path Demo (Deterministic)

  1. Challenge: hello world -> HELLO WORLD!
  2. Solution: gU$A!<Esc>

3.7.3 Failure Demo (Deterministic)

If you use v$gU instead of gU$, you add extra keystrokes and break the golf goal.

3.7.4 If CLI

Not applicable.

3.7.5 If Web App

Not applicable.

3.7.6 If API

Not applicable.

3.7.7 If Library

Not applicable.

3.7.8 If TUI

+-------------------------+
| vim_golf.md             |
| Challenge: teh -> the   |
| Solution: xp            |
| -- NORMAL --            |
+-------------------------+

Vim golf screen

Key interactions:

  • Operator + motion
  • Dot repeat
  • Counts

4. Solution Architecture

4.1 High-Level Design

+------------------+    +-------------------+    +------------------+
| Challenge List   | -> | Minimal Solutions | -> | Keystroke Log     |
+------------------+    +-------------------+    +------------------+

Vim golf pipeline

4.2 Key Components

Component Responsibility Key Decisions
Challenge set Provide edits to solve Include variety
Solutions Provide minimal commands Count keystrokes honestly
Log Track results Use Markdown table

4.3 Data Structures (No Full Code)

ChallengeEntry:
- description
- solution
- keystrokes
- alternative

4.4 Algorithm Overview

Key Algorithm: Minimal Edit Search

  1. Describe the edit.
  2. Try operator+motion solution.
  3. Compare with Visual-mode solution.
  4. Choose minimal keystroke count.

Complexity Analysis:

  • Time: O(k) per challenge
  • Space: O(1)

5. Implementation Guide

5.1 Development Environment Setup

vim --version

5.2 Project Structure

vim-golf/
|-- vim_golf.md
`-- solutions_log.md

5.3 The Core Question You’re Answering

“Is there a faster way to express this edit?”

5.4 Concepts You Must Understand First

  1. Operator + motion grammar
  2. Dot repeat and counts
  3. Case operators and %

5.5 Questions to Guide Your Design

  1. Can I avoid Visual mode entirely?
  2. Can I use a larger motion to reduce keystrokes?
  3. Is the change repeatable with .?

5.6 Thinking Exercise

Find the shortest way to change teh to the.

5.7 The Interview Questions They’ll Ask

  1. “How do you swap two characters?”
  2. “What does ~ do?”
  3. “How do counts reduce keystrokes?”

5.8 Hints in Layers

Hint 1: Operators beat Visual gU$ beats v$gU.

Hint 2: Use . One good change, then repeat.

Hint 3: Use xp xp swaps two characters.

Hint 4: Counts 3w beats www.

5.9 Books That Will Help

Topic Book Chapter
Efficiency “Practical Vim” Ch. 1

5.10 Implementation Phases

Phase 1: Define Challenges (1-2 hours)

Goals:

  • Create 10 editing challenges.

Tasks:

  1. Write challenges that cover case, motion, deletion, and swaps.
  2. Ensure challenges are clear and reproducible.

Checkpoint: Challenge list is complete.

Phase 2: Solve Minimally (2-4 hours)

Goals:

  • Find the shortest command sequences.

Tasks:

  1. Solve each challenge using operator grammar.
  2. Record keystrokes.

Checkpoint: Each challenge has a solution.

Phase 3: Compare and Improve (ongoing)

Goals:

  • Iterate on solutions to reduce keystrokes.

Tasks:

  1. Revisit solutions weekly.
  2. Find at least one improvement.

Checkpoint: Keystroke counts decrease over time.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Challenge difficulty Easy / Mixed / Hard Mixed Wider skill range
Solution logging Inline / table Table Quick comparison
Practice cadence Daily / weekly Weekly Sustainable

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Reproducibility Ensure solution works Run on fresh buffer
Keystroke count Verify minimality Count with :set showcmd
Repeatability Use . where possible Apply to multiple lines

6.2 Critical Test Cases

  1. Case-change challenge using gU.
  2. Character swap challenge using xp.
  3. Multi-line change using n ..

6.3 Test Data

hello world
teh
alpha beta gamma

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Overusing Visual Extra keystrokes Use operator+motion
Counting wrong Overcounted solution Use :set showcmd
Ignoring . Repeating manually Use dot repeat

7.2 Debugging Strategies

  • Re-run the challenge in a fresh buffer.
  • Compare two solutions side by side.

7.3 Performance Traps

  • Optimizing for a single case and ignoring repeatability.
  • Using complex macros where a simple motion works.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Solve 5 challenges under 10 keystrokes.
  • Avoid Visual mode entirely for one challenge.

8.2 Intermediate Extensions

  • Use g~ for case toggling challenges.
  • Create a challenge involving % jumps.

8.3 Advanced Extensions

  • Submit a solution to vim-golf online.
  • Create a personal benchmark for weekly improvement.

9. Real-World Connections

9.1 Industry Applications

  • Faster refactors and quick fixes.
  • Efficient edits in high-pressure debugging sessions.
  • vim-golf (online challenges).
  • Vim communities sharing minimal solutions.

9.3 Interview Relevance

  • Demonstrates tool mastery and disciplined editing.

10. Resources

10.1 Essential Reading

  • “Practical Vim” Ch. 1 and 5

10.2 Video Resources

  • Vim golf walkthroughs

10.3 Tools & Documentation

  • :help gU
  • :help .

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain why operator+motion is shorter than Visual.
  • I can use dot repeat deliberately.
  • I know at least three case operators.

11.2 Implementation

  • Completed 10 challenges with logged keystrokes.
  • Found at least one alternative solution per challenge.
  • Improved at least one solution over time.

11.3 Growth

  • I can design new challenges for practice.
  • I can teach Vim golf principles to someone else.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Solved 10 Vim golf challenges with keystroke counts.
  • Used operator+motion solutions for at least half.

Full Completion:

  • All minimum criteria plus:
  • Reduced at least one solution after revisiting.
  • Used dot repeat in at least three challenges.

Excellence (Going Above & Beyond):

  • Contributed a solution to an online Vim golf challenge.
  • Built a personal benchmark chart for improvement.