kakoune-lsp brings language server support to a modal editor

A client for a modal editor that ships with no language tooling

The problem is that Kakoune is deliberately small, and it ships without the language intelligence that a programmer expects. kakoune-lsp is a client for the Language Server Protocol that fills that gap. The README states the requirement plainly, that it is a client for Kakoune version v2021.11.08 or higher, which is a specific floor rather than a vague recent version. The intended user is a Kakoune user on a recent enough build who wants completions, navigation and diagnostics without leaving the editor's model, and who has a language server already available or is willing to install one. The quick start in the README is a five step list, and the last two steps, configuring key mappings and the modeline, are not optional extras but part of getting the thing usable.

Installing means a package manager or a tarball and a PATH entry

Distribution is handled through the ecosystem rather than by the project. There are packages for Alpine Linux with apk, for Arch Linux with pacman and an AUR variant, for FreeBSD with pkg add, a Fedora Copr, a Homebrew tap, openSUSE, and Void Linux with xbps-install. The manual route is a set of curl lines that pick the archive matching your platform, Darwin arm64, Darwin x86_64, or Linux x86_64, followed by extracting the tarball and moving the kak-lsp directory into a location on your PATH, with the README suggesting you replace ~/.local/bin/ with something of your own. The binary is called kak-lsp even though the project is kakoune-lsp, which is a small inconsistency you will hit the first time you look for it in your PATH. Building from source is a cargo install into your cargo bin directory, which has to be on your PATH:

git clone https://github.com/kakoune-lsp/kakoune-lsp
cd kakoune-lsp
# this installs the kak-lsp binary to ~/.cargo/bin, which must be in your `$PATH`
cargo install --locked --force --path .

The Makefile at the root is the packaging side, with a build target that runs cargo build with the release profile and locked dependencies, and an install target that puts the binary in the bin directory and the two rc files beside it.

The client does not install language servers, and you maintain the list

This is the point that trips up newcomers. The README says kakoune-lsp does not manage installation of language servers, and you install them yourself. What the client does ship is a default set of servers that work out of the box once installed, and you can see that set in the rc/servers.kak file, or print it from a running Kakoune with a one-line command that executes the client's hook and dumps the filetype mapping. So the setup order is: install the servers you actually want, then check that the client agrees with your choice. The rc/ directory at the root holds the Kakoune-side files, lsp.kak and servers.kak, and the Makefile installs both of them into the share directory under the package name, so an installed client and its Kakoune configuration travel together. The Cargo.toml also names the two authors, Ruslan Prokopchuk and Johannes Altmanninger, and the crate is published as kak-lsp with the version tracked as a snapshot of the release.

Enabling LSP in Kakoune is one line, or a filetype hook

The integration with Kakoune itself is deliberately thin. To turn on LSP support for every configured language you add an eval of the client script and then the lsp-enable command to your kakrc:

eval %sh{kak-lsp}
lsp-enable

If you only want it in some filetypes, the alternative is a window hook that calls lsp-enable-window, and the README's example hooks on rust, python, go, javascript, typescript, c and cpp:

eval %sh{kak-lsp}
lsp-enable
----

Alternatively, enable LSP only for specific filetypes you need
via `lsp-enable-window`, e.g.:

[source,kak]
----
eval %sh{kak-lsp}
hook global WinSetOption filetype=(rust|python|go|javascript|typescript|c|cpp) %{
    lsp-enable-window

The distinction between enabling globally and enabling per window matters more in Kakoune than in a normal editor, because a global enable starts a server per buffer filetype, and that is a process per language rather than a connection you can toggle cheaply. The two commands therefore exist for different levels of appetite, and picking the window-scoped one is the conservative default for a large filetype set.

The key mappings assume you know what a goto buffer is

The recommended mappings are a good tutorial for the feature set, and they assume familiarity with Kakoune's select mode. The modeline gains a slot for the LSP status through the lsp_modeline option, and the mappings use the normal Kakoune idiom of entering user mode with a semicolon and then calling the lsp command. Under goto, d goes to the definition, r to the references and y to the type definition, each leaving the normal mode with escape first. Under object, a and a-semicolon go to any symbol, f restricts it to a function or method, t to a class or module, and d and D jump to the diagnostic object with the error and warning severities or errors only. The insert mode mapping for snippets uses a try and catch around lsp-snippets-select-next-placeholders, so a failed selection does not leave a stray keystroke in the buffer, which is a small piece of engineering that only makes sense to someone who has written Kakoune scripts.

Hover, diagnostics and a goto buffer that behaves like a jump list

The command set beyond navigation is where the editor integration shows. lsp-hover shows hover information including relevant diagnostics in the info box, and lsp-hover-buffer shows the same in a scratch buffer, with lsp-auto-hover-enable and lsp-auto-hover-buffer-enable for the automatic version, and an option to anchor the hover to the hovered position or to format the output yourself with a printf format string. lsp-find-error jumps to the next or previous error in the file, and lsp-selection-range selects interesting ranges around the current selection, with a companion command to move between them. There is also a polyfill of the jump commands for buffers with the lsp-goto filetype, and the README notes these work for grep, lint and make buffers too, which is a neat trick: the same jump list mechanism serves the language server and your build output.

The version skew note is the most important line in the README

There is a warning that most projects bury, and here it is load-bearing. The README notes that the contents below correspond to the master branch HEAD and could be slightly out of sync with the version installed from pre-built binaries, with the most common case being new commands still in a pre-release testing stage, and it advises referring to the README.asciidoc revision tagged with the version you use, or the one from the release archive. In practice that means the documentation you are reading on the default branch may describe a command your installed binary does not have. The Cargo.toml is explicit about the toolchain, with a rust-version of 1.75 and an edition of 2018, and the release profile enables link time optimisation, which is reasonable for a binary that is going to sit in your editor's path. The last push to the repository was on 2026-10-14, with v22.0.0 tagged on 2026-10-06.

A permissive licence and a dual-file setup

The licensing is unusual in a good way. The repository root carries both an MIT file and an UNLICENSE file, and the Cargo.toml records the licence as Unlicense/MIT, so the code is available under either a permissive MIT grant or a public domain dedication, and the Makefile installs the UNLICENSE text as the licence file for the package. The rest of the repository is conventional for a Rust project, with a Cargo.toml and Cargo.lock, a rustfmt.toml, a CHANGELOG.md, a CONTRIBUTING file, ci/ and test/ directories, and .github/ for the workflows. The rc/ directory is the part that is specific to this project, and it is where the Kakoune-side configuration lives, which is what the Makefile copies into the share directory on install.

Editorial conclusion

kakoune-lsp suits a Kakoune user who wants language intelligence without leaving the editor's model, and who is willing to maintain a server list and keep a Kakoune version matched to the client. It does not suit a team that wants a single IDE with one install path, because the client, the language servers and the editor are three separate pieces. Before adopting, check the Kakoune version requirement, install the language servers yourself since the client does not manage them, and note that the last push to the repository was on 2026-10-14 with release v22.0.0 dated 2026-10-06.

Frequently asked questions

Official sources

1. kakoune-lsp/kakoune-lsp on GitHub
2. License: Unlicense
3. Project website
4. README
5. Releases