Helix 25.07.1: one binary, thirteen library crates, and a release older than a year

default-members is helix-term, so the other thirteen crates are libraries

Cargo.toml declares a resolver 2 workspace with fourteen members: helix-core, helix-view, helix-term, helix-tui, helix-lsp-types, helix-lsp, helix-event, helix-dap-types, helix-dap, helix-loader, helix-vcs, helix-parsec, helix-stdx, and xtask. Then it narrows the default to a single entry, default-members is helix-term. Consequence: a plain cargo build in a clone produces one binary, and everything else in the tree is a library crate with no executable of its own, so if you were expecting a set of tools checked out side by side there is only one. The profiles are where the performance decisions are written down. Release uses thin LTO. A separate profile named opt inherits release and switches to fat LTO, codegen-units set to 1, strip enabled, opt-level 3. A third, integration, inherits test and raises opt-level to 2 for helix-core, helix-tui and helix-term, so the hot path is not measured in a debug build. The workspace package sets version 25.7.1, edition 2021, license MPL-2.0, and rust-version 1.90.

The newest tag is 25.07.1 from 2025-07-18 and master has moved on since

The release names are date stamped. 25.01.1 shipped on 2025-01-19, 25.07 on 2025-07-15, and 25.07.1 on 2025-07-18, that last one three days after its own minor. The workspace version in Cargo.toml is the same 25.7.1. The repository itself was pushed on 2026-09-29, so the gap between the newest tag and the newest commit is over a year, and the project is not archived. That gap is the practical fact for anyone installing. A package manager hands you whatever that distribution built, which may be a build of master rather than of the tag, and the README names no nightly or rolling channel to ask for. Building from source gives you something no release has ever shipped, described only by CHANGELOG.md. There is also no compatibility promise in either direction, so pinning a Helix version is a decision about which commit your configuration meets, not about which feature set you get.

The feature list names four things, and the workspace ships two more unmentioned

The feature section is four lines: Vim-like modal editing, multiple selections, built-in language server support, and smart, incremental syntax highlighting and code editing via tree-sitter. The workspace members tell a longer story. helix-dap and helix-dap-types are Debug Adapter Protocol crates, and helix-vcs is a version control crate, and neither debugging nor version control integration appears in the feature list. Consequence: do not plan a debug-driven or VCS-driven workflow from this overview, because the overview does not claim either, and go to CHANGELOG.md and the documentation site instead. There is also a line about a custom renderer similar to Emacs using wgpu, phrased as an interest rather than a plan, which tells you the terminal is the shipped interface and anything graphical is exploratory. The README is written throughout in the first person singular, including the remark that during development the author found himself agreeing with most of Kakoune's design decisions, which is a fair signal about the size of the project and its decision making.

indents.scm exists for only some languages, and the path to check is named

One line in the README is the most operationally useful sentence in it: only certain languages have indentation definitions at the moment, and you check runtime/queries/<lang>/ for indents.scm. That splits the headline feature in two. tree-sitter gives you parsing and incremental highlighting for the languages whose grammars are in the tree, and automatic indentation is a separate query file per language that is not present for all of them. Consequence: on a language with no indents.scm you get correct syntax colouring and no automatic indent, which in a language with meaningful indentation produces a file that looks wrong on screen even though nothing is broken. There is no fallback named and no flag named for disabling the behaviour, so the diagnostic step is to look for the file. The rest of the runtime configuration sits in two visible places: languages.toml at the top level for language definitions, and runtime/ for the query set, with grammars.nix managing the grammar side for Nix based setups.

helix-lsp-types and helix-dap-types are in-tree, so protocol support is pinned to the editor

The workspace carries its own protocol type crates, helix-lsp-types and helix-dap-types, rather than depending on externally published type packages. That is a deliberate choice with a direct consequence: the shape of the language server and debug adapter protocols you can speak is frozen at whatever the editor build contains. If your language server was written against a newer protocol revision and uses a request or capability this build has no type for, the gap is closed by upgrading the editor, not by changing the server, and a package manager install a year behind master is a year behind on that too. The rest of the dependency list is short and telling. ropey is declared with default-features off and the simd feature explicitly enabled, so the text buffer always takes the vectorised path regardless of defaults. nucleo supplies fuzzy matching, termina handles terminals, etcetera resolves configuration directories, and toml, sonic-rs, globset, arc-swap, parking_lot, thiserror, bitflags, slotmap, unicode-segmentation, foldhash, and arrayvec fill in the rest.

Installation is a documentation link, and the keymap is a website page

The installation section carries no command at all. It is a link to the installation documentation at docs.helix-editor.com/install.html, followed by a Repology link, which is the machine readable index of which distributions package Helix and at what version. So a reader has to leave the repository to learn how to install, which is unusual but not a gap: the repository carries everything a packager needs, including flake.nix, flake.lock, shell.nix, default.nix, grammars.nix, an .envrc for direnv, a committed Cargo.lock, and Cargo.toml for the workspace shape. Other documentation is also split across locations rather than in the tree. Shortcuts and keymaps are published at docs.helix-editor.com/keymap.html, not in the repository, so grep will not find a binding. Contributor guidance sits at docs/CONTRIBUTING.md, there is a docs directory and a book directory for the longer form, and troubleshooting plus the FAQ live in the repository wiki. Community discussion is on Matrix in #helix-community:matrix.org.

Multiple selections are why the Kakoune keybindings will not transfer from Vim

The lineage is stated plainly: the editor is inspired by Kakoune and Neovim, and the editing model is very heavily based on Kakoune. Combined with multiple selections as a headline feature, that fixes the semantics of a normal mode command. In a single cursor editor a command acts on the cursor position, in a multiple selection editor the equivalent command acts on every selection at once, so a key you have pressed ten thousand times in another editor means something else here. Consequence: migrating is a relearning exercise, not a reconfiguration, and the README names no compatibility layer and no keymap translation mechanism, so there is no cheap middle path. What you get for the cost is the reason people stay: one edit touches every occurrence without a search, a macro, or a plugin. Note also the Matrix fallback, since a client without Matrix Spaces support needs to join #helix-editor:matrix.org instead, and the credits line, where the logo is by @jakenvac. The project is licensed MPL-2.0.

Editorial conclusion

Helix fits a reader who wants the Kakoune model, is willing to relearn keybindings instead of translating them, and can live with a documentation site instead of a README. It does not fit a reader who needs automatic indentation on every language, who needs a debug adapter or version control integration described anywhere in the project's own overview, or who wants a release cadence close to the commit rate. Before you adopt it, check five things: which languages actually ship an indents.scm under runtime/queries/, since only some do and there is no fallback; which build you are installing, because the newest tag is 25.07.1 from 2025-07-18 while master has moved since; whether your Rust toolchain is 1.90 or newer, which is the declared rust-version; whether the protocol features your language server needs exist in this build's in-tree helix-lsp-types; and where you will read the keymap, since it lives on the website rather than in the repository.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes