Every few years a text editor comes along that asks a slightly different question about how we move around code. Vim asked it with modes and composable commands. Kakoune and Helix asked it again by putting the selection first. Ki asks it once more, with an idea that sounds small but changes how editing feels: every movement happens inside an explicitly chosen selection mode, and one of those modes is the syntax tree of your code.
This post explains what Ki is, what’s genuinely different about it, and who it’s for. It’s based on the project’s documentation and source repository. There’s no invented benchmark here, because the interesting thing about Ki is its design, not a performance number.
The quick facts
- What it is: the project describes itself as a “multi-cursor combinatoric modal editor”, with first-class support for working on syntax nodes.
- Written in: Rust.
- Parsing: uses Tree-sitter, the incremental parsing library behind syntax-aware features in Neovim, Helix, Zed and others.
- Where it runs: primarily as a terminal editor, with extensions in the repository for VS Code and JetBrains IDEs.
- Licence: MPL-2.0.
- Source: github.com/ki-editor/ki-editor, with prebuilt binaries on the releases page and a community chat on Zulip.
The core idea: selection modes plus movements
In Vim, you combine an operator with a motion: d plus w deletes a word. Motions and text objects are a big vocabulary you gradually learn. Ki splits this differently.
First you choose what kind of thing you’re working with: that’s the selection mode. Examples include words, lines and syntax nodes. Then you choose where to go: that’s the movement, such as next, previous, first, last or jump.
The docs put the rule plainly: “All movements must be paired by a preselected selection mode.” The pay-off is that the same small set of movement keys works for every kind of unit. “Next” means the next word in word mode, the next line in line mode, and the next sibling node in syntax-node mode. You learn the movements once and reuse them everywhere, instead of learning a separate command for each kind of object.
As the documentation puts it, by combining movements and selection modes, you can express almost any movement you can think of. That’s what “combinatoric” means in the project’s description.
Why syntax-node mode matters
The feature that gets people’s attention is treating syntax nodes as a first-class selection mode. Because Ki uses Tree-sitter, it knows that a particular span is a function call, an argument, a parameter list or an if block. In syntax-node mode, “next” moves to the next node at the same level, so you can hop from argument to argument or statement to statement without counting words or characters.
That’s especially nice for edits like:
- selecting a whole function argument, including the awkward nested ones, in one step,
- reordering items in a list or parameters in a signature,
- deleting an entire expression without worrying about stray brackets,
- putting cursors on every matching node and editing them together.
What Ki is not
It’s worth correcting a claim you’ll find in some write-ups: Ki is not a projectional editor. You’re still editing text, and it’s entirely possible to type invalid code. The syntax tree helps you select and move precisely. It doesn’t stop you from making syntax errors. Structural selection makes a whole class of fiddly mistakes less likely, like deleting half an expression, but you’ll still see compiler errors.
Ki is also not a refactoring engine. Renaming a symbol across a project, extracting a function and similar semantic operations come from language servers. Ki can use LSP like other modern editors, but the structural selection itself is about where your cursor goes, not about understanding what your code means.
Positional keymaps
One unusual design choice: Ki’s keymaps are strictly positional rather than mnemonic. In Vim, d means delete because “d” starts the word. Ki instead assigns related actions to physical key positions. The docs give the example that copying and then pasting the current selection is done by pressing c then b on a QWERTY layout.
The benefit is that Ki behaves the same on QWERTY, Dvorak, Colemak or any other layout: the key in that position does the same thing. The cost is that you can’t guess commands from their names, so you learn the layout the way you’d learn an instrument. The core concepts page and the built-in help are the best places to start. I’d recommend learning from them directly instead of from third-party cheat sheets, some of which list keys that don’t match the real keymap.
Multiple cursors, done properly
Multi-cursor editing is built into Ki’s core rather than added on. Combined with selection modes, that means you can select every match of a node or word, move them all together with the same movement keys, and edit in parallel. If you’ve used Kakoune or Helix, this will feel familiar. If you come from Vim, it replaces a lot of macros and :s commands with direct, visible editing.
How it compares with Vim, Helix and Kakoune
Vim/Neovim use a verb-then-object grammar with a large vocabulary of motions. They have a huge ecosystem and plugins for almost anything, including Tree-sitter text objects. The model is powerful but uneven: each kind of object has its own commands.
Kakoune and Helix flip Vim’s grammar to select first, then act, and put multiple selections at the centre. Helix ships with Tree-sitter and LSP built in. Ki shares that selection-first philosophy.
Ki goes further in making the unit of selection an explicit mode that every movement respects, and in treating syntax nodes as a peer of words and lines rather than a special add-on. If Helix’s model already clicks for you, Ki is a natural thing to try. If you’ve spent fifteen years building Vim muscle memory, expect a real learning curve.
Getting started
- Download a release for your platform from the GitHub releases page. The repository also includes a Nix flake if that’s how you manage tools.
- Open a small project in a language with good Tree-sitter support, such as Rust, TypeScript or Python, so syntax-node mode has something to work with.
- Spend your first session only on selection modes and movements. Switch to word mode, move; switch to line mode, move; switch to syntax-node mode, move. Once that clicks, everything else builds on it.
- If you live in VS Code or a JetBrains IDE, look at the extensions in the repository. Check their current state before relying on them, since they’re newer than the terminal editor.
Who should try it
Ki is a good fit if you like modal editing but have felt that Vim’s grammar is a pile of special cases, or if you already use Helix and want to go further with structural editing. It’s also interesting for anyone who thinks about editor design, because its “mode plus movement” idea is simple enough to explain in a sentence and deep enough to change how you edit.
It’s probably not the right choice if you need a mature plugin ecosystem today, or if your team depends on shared editor configurations. Like most young editors, it’s best tried on a side project first.
Either way, it’s worth an afternoon. Even if you go back to your usual editor, you may find yourself thinking about code less as lines of text and more as the tree it really is. For more on that tree, see our developer’s guide to abstract syntax trees.
