# Kakoune: A Modal Editor Built Around Multiple Selections

> Kakoune is a C++20 modal code editor that treats selections as the primary unit of editing and keeps most operations incremental. It is a strong fit for engineers comfortable with Vi-style keystroke grammar who want selection-first editing and a client-server session model.

**mawww/kakoune** — mawww's experiment for a better code editor

- Repository: https://github.com/mawww/kakoune
- Website: http://kakoune.org
- Stars: 11,075 · Forks: 783
- Language: C++
- License: Unlicense
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/mawww-kakoune

## What Kakoune Is and Who It Is For

Kakoune is a code editor that implements Vi's "keystrokes as a text editing language" model, according to the README. It has two modes, normal and insertion. In insertion mode keys go straight into the buffer. In normal mode keys manipulate the current selection or enter insertion mode. The README says the project was originally inspired by Vim, so the surface syntax will look familiar to anyone who has used it.

The audience is narrower than "anyone who wants a modal editor." Kakoune is for engineers who are willing to treat selections as the central object. The README lists "multiple selections as a central way of interacting" as the first feature and the design document is referenced as the place where the philosophy lives. If you want a modal editor that behaves like Vim with a few extra commands, this is a different mental model. If you already use block selection or search-and-replace heavily, the model maps onto work you do anyway.

The README also points to a separate repository, mawww/golf, for Kakoune solutions to vimgolf challenges, and claims those solutions regularly beat the best Vim solution. That is a claim about keystroke count on a specific class of puzzles, not a general productivity measurement, and the README does not quantify it.

## How the Selection Model and Client-Server Split Work

Kakoune works on selections, which the README defines as oriented, inclusive ranges of characters. A selection has an anchor and a cursor. Most commands move both. When you extend a selection, the anchor stays fixed and the cursor moves. That single rule explains a lot of the editing feel: extending is a distinct operation from moving, and the anchor is the thing you reason about when you want to grow or shrink a range.

On top of that primitive the README lists selection manipulation commands: select all regex matches in current selections, keep selections containing or not containing a match for a given regex, split current selections with a regex, and text objects for paragraph, sentence and nestable blocks. Text manipulation includes aligning selections, rotating selection contents, case manipulation, indentation and piping each selection to an external filter. The pipe-to-filter feature is the one that most changes day-to-day work, because it turns any Unix command into a text transformation over each selection independently.

The architecture is client-server. The README states that multiple clients can share the same editing session, and that you use tmux, zellij, kitty, wezterm or your X11/Wayland window manager to manage splits and panes by spawning clients connected to the same session. The editor core is not the terminal multiplexer, and the multiplexer is not the editor. That separation is why the README can list several terminal emulators as equally valid pane managers. Syntax highlighting supports multiple languages in the same buffer, and the README notes a buffer can be highlighted differently in different windows.

## Building Kakoune from Source and Installing It

The README's TL;DR is a three-line build. The dependency is a C++20 compliant compiler (GCC >= 10.3 or clang >= 11) along with its standard library (libstdc++ >= 10 or libc++). The README says to type make in the root directory.

```bash
git clone https://github.com/mawww/kakoune.git
cd kakoune
make
./src/kak
```

Running ./src/kak starts the editor directly from the source tree without installing it. To generate man pages, the README says to run make man in the root directory.

For a system install, the README says to run make install and that PREFIX and DESTDIR can be specified. The Makefile confirms the defaults: PREFIX = /usr/local, DESTDIR empty, binaries under $(PREFIX)/bin, libexec under $(PREFIX)/libexec/kak, shared files under $(PREFIX)/share/kak, docs under $(PREFIX)/share/doc/kak and man pages under $(PREFIX)/share/man/man1.

```bash
make
sudo make install
```

Package managers are the shorter path on most systems. Homebrew and Linuxbrew use brew install kakoune. Fedora uses dnf install kakoune, and a copr repository, jkonecny/kakoune, provides daily builds via dnf copr enable jkonecny/kakoune followed by dnf install kakoune. RHEL/CentOS 8 pulls from EPEL8 with dnf install kakoune. Arch uses pacman -S kakoune. Debian 9 (Stretch) and later and Ubuntu both use sudo apt install kakoune. Gentoo uses emerge kakoune, openSUSE uses sudo zypper install kakoune, MacPorts uses sudo port install kakoune, FreeBSD uses pkg install kakoune, and Exherbo uses cave resolve -x repository/mawww then cave resolve -x kakoune.

The README gives one platform-specific build note: on Ubuntu 20.04 or earlier you must force GCC 10, which is not the default, and make sure .local/bin is in your path so kak is available after installation. The README's example installs to $HOME/.local.

```bash
git clone https://github.com/mawww/kakoune.git && cd kakoune/src
CXX=g++-10 make
make PREFIX=$HOME/.local install
```

After installation, the command is kak. The README's feature list mentions automatic contextual help and as-you-type completion, both of which are available without configuration. The rc/ and colors/ directories at the repository root hold the runtime configuration and color schemes that get installed under share/kak.

## Where Kakoune Does Not Fit

The clearest boundary is Windows. The README states that because Kakoune relies heavily on being in a Unix-like environment, no native Windows version is planned. Cygwin is listed as a supported build target, so the path on Windows is a compatibility layer, not a native port. If your team standardizes on Windows without Cygwin or a similar environment, this is the wrong editor.

The second boundary is ecosystems. The README lists macros, hooks, syntax highlighting and interaction with external programs, and the repository has a contrib/ directory, but the README does not describe a plugin manager or a package registry. Whatever extension model exists is not documented in the README, so anyone whose workflow depends on a large third-party plugin set should verify that before committing. The VIMTOKAK file at the repository root suggests the project ships a conversion aid for Vim configuration, but the README does not explain its scope.

A third issue is version lag in distribution packages. The README notes that on Ubuntu 20.04 or earlier you must force GCC 10 to build from source, which implies the packaged version on older releases may not match what the source tree produces. The release history shows v2026.05.21, v2026.04.12 and v2025.06.03, so releases arrive irregularly rather than on a fixed cadence. The README does not document a rollback path or a downgrade procedure, so plan upgrades around the package manager you use.

## Kakoune Compared with Vim, Neovim and Helix

Vim and Neovim share Kakoune's modal grammar but not its selection model. In Vim, the cursor is the unit and visual mode is a temporary state you enter to operate on a range. In Kakoune, a selection always exists and commands act on it. The README's phrasing is that Kakoune implements Vi's keystroke language while working on selections. The practical difference shows up in multi-cursor work: selecting all regex matches and then editing each one is a first-class operation in Kakoune, whereas in Vim it is a plugin concern or a macro. Neovim keeps Vim's model and adds an embedded Lua runtime and a plugin API; the README does not describe an equivalent scripting runtime for Kakoune beyond hooks and macros.

Helix is a closer comparison because it also puts multiple selections at the center. The difference is the direction of the grammar. Kakoune follows Vi's verb-then-object order, so you press the operation and then the motion. Helix, as commonly described, uses selection-first ordering. The README does not discuss Helix, so the comparison rests on the shared premise of multiple selections rather than on any statement in the repository. If you already have Vi muscle memory, Kakoune preserves it; Helix asks you to relearn the order.

The client-server split is the other difference worth naming. The README describes spawning clients from tmux, zellij, kitty, wezterm or an X11/Wayland window manager, all attached to one session. That is a deliberate choice to delegate pane management to existing tools rather than build splits into the editor. Editors that embed their own window management give you one binary to configure; Kakoune gives you a smaller editor that composes with what you already run.

## Maintenance, Licensing and Upgrade Cost

The repository is not archived. The last push was on 2026-09-15, and the most recent release in the list is v2026.05.21 from 2026-05-21, followed by v2026.04.12 and v2025.06.03. Releases are not evenly spaced: roughly a month between the two 2026 spring releases, then about eleven months back to the 2025 release. Commits and releases are therefore not the same signal, and pinning to a tag is more predictable than tracking master.

The licence is the Unlicense. That is a public-domain dedication rather than a permissive licence with attribution conditions, which removes the attribution requirement that MIT or BSD would impose. The repository root contains a UNLICENSE file. This is a description of what the repository states, not legal advice; if your organization has a policy on public-domain dedications, check it against the UNLICENSE text rather than against this summary.

Upgrade cost depends on how you installed it. Package manager installs move when the distribution moves, and the README's Ubuntu note about forcing GCC 10 on 20.04 or earlier is a reminder that older releases can lag the source tree. Source builds are a make away, but the Makefile reads the version from .version if present, otherwise from git describe --tags HEAD, falling back to unknown. A build from a tarball without .version and without git metadata will report an unknown version, which matters if you need to correlate a binary with a release. The README does not document a rollback procedure, so keep the previous binary or package until you have confirmed the new one.

## Conclusion

Kakoune suits engineers who already think in Vi keystroke grammar and want selections, not single cursors, as the unit of editing, plus a client-server session they can attach to from tmux or a terminal emulator. It is the wrong tool if you need a native Windows build, since the README states none is planned, or if you depend on a mature plugin ecosystem, since the README does not describe one. Before adopting it, check that your distribution package is current or build from source, and read doc/design.asciidoc to confirm the selection model matches how you edit.

## FAQ

### What are the disadvantages of Kakoune?

There is no native Windows version and the README states none is planned, so Windows users need Cygwin or a similar Unix-like environment. The README also does not describe a plugin manager or package registry, which limits anyone whose workflow depends on a large third-party ecosystem.

### How do you use Kakoune?

Kakoune runs in normal and insertion modes. In normal mode keys manipulate the current selection or enter insertion mode, and in insertion mode keys go directly into the buffer. Most commands act on selections, which are oriented, inclusive ranges with an anchor and a cursor.

### Is Kakoune dead?

The repository is not archived, and the last push was on 2026-09-15. The most recent release listed is v2026.05.21 from 2026-05-21, after v2026.04.12 and v2025.06.03, so releases arrive irregularly rather than on a fixed schedule.

### How does Kakoune compare with Vim and Neovim?

All three use Vi's keystroke-as-language model, but Kakoune works on selections as its central abstraction, while Vim and Neovim center on a cursor with visual mode as a temporary state. The README says Kakoune was originally inspired by Vim and lists multiple selections as its first feature.

### How does Kakoune compare with Helix?

Both put multiple selections at the center of editing, but Kakoune follows Vi's verb-then-object ordering while Helix uses selection-first ordering. The README does not discuss Helix, so the shared premise of multiple selections is the comparable point rather than any statement in the repository.

## Sources

- [License: Unlicense](https://github.com/mawww/kakoune/blob/master/LICENSE)
- [mawww/kakoune on GitHub](https://github.com/mawww/kakoune)
- [Project website](http://kakoune.org)
- [README](https://github.com/mawww/kakoune/blob/master/README.md)
- [Releases](https://github.com/mawww/kakoune/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mawww-kakoune