Marmotype

At a glance

• Outcome: Fast local practice with no browser and no account: type drills built around awkward letter chunks instead of whole words, with a finger guide that names the movement instead of the key, and Vim motion practice scored by keystroke count rather than by quiz.
• Status: In development. Both halves run and are usable; neither is finished, and merging them is the current plan instead of a shipped fact.
• Role: Solo.
• Stack & libraries: Marmotype: Rust with Ratatui for the TUI and Crossterm for terminal control. It builds to a single binary, but only the Linux release build is verified; macOS and Windows are planned targets, with no CI or packaging in the repo yet. vim-gym: Python 3.11+, standard library only, with no runtime dependencies at all.
• What I got out of it: Modeling a keyboard as data rather than as a lookup table, Ratatui layout and resize handling, Crossterm raw input, and building a usable TUI in Python with nothing but stdlib.
• Source: Private.
• Limitations: Both are built for one user. The fragment list is 21 hand-authored strings and the schedule that serves them is fixed, so nothing measures which chunks you are bad at. Custom mode is selectable but drills a placeholder, there’s no reachable way to load your own keyboard profile, and the merge hasn’t happened.

The idea

Most typing trainers drill whole words, which means most of your practice time goes to the parts you’re already fine at. What actually slows you down is a handful of awkward letter chunks like nly, umpt, ptio, tion and ough, and those get about two seconds of attention per paragraph.

Marmotype makes those a first-class token kind instead of a separate app bolted on: word drills slot a fragment in every fifth token, sprints every seventh, and Fragment mode is nothing but fragments. The schedule is fixed and the list is hand-picked. Nothing yet weights toward the chunks a particular person fumbles. The point so far is that the awkward chunks show up at all.

The guide names a movement, not a key

The part I’d point at is the finger guide, because the unit it works in isn’t a key. It’s a movement. For each character the app works out which finger owns the key, where that finger rests, and which way it has to travel, so the hint reads left middle, D to E, move up instead of press E. It has enough tolerance that a same-row nudge correctly reads as staying put.

That works because the keyboard is modeled as separate tables for key geometry, layer bindings, finger ownership and home positions, instead of one QWERTY character-to-finger map. Everything the UI knows about keyboards arrives in a single resolved hint, so describing a split or remapped board is a new profile rather than new UI code. Wide terminals draw the whole board from the layout’s own coordinates; narrow ones fall back to the compact movement line.

The honest gap: that profile loading exists in the layout module but isn’t reachable from the app yet, so today it always describes the built-in board.

The Vim half

The same argument applies to Vim. The gap isn’t knowing that dw deletes a word. It’s that under pressure you reach for xxxxxxx anyway, and a cheat sheet never tells you the thing you just did took eleven keystrokes and could have taken three.

vim-gym scores that directly, across three modes: a command quiz for the knowledge layer, a speedrun that measures what your edit actually cost, and VimGolf-style puzzles where the whole point is the shorter path.

Stdlib-only was a choice. A practice tool you have to set up an environment for is one you don’t open.

Where it’s going

These started as two repos and are converging into one: vim-gym’s motion practice becomes a mode inside Marmotype, alongside the word and fragment drills. Both are terminal-first practice for muscle memory, and keeping them apart means two scoring systems, two histories, and two things to open.

That merge is the plan, not a thing that’s done, which is why this page covers both instead of claiming a finished tool.