Helix selects first and edits second
Helix is a modal editor, but calling it another Vim clone gives the wrong expectation. Its commands follow Kakoune's selection-first model: select the text, see the target, then apply an action. Multiple selections are a normal editing primitive rather than a special mode. Language Server Protocol support and tree-sitter parsing live in the editor, alongside fuzzy file picking and syntax-aware movement. The result is appealing if you want a serious terminal workspace without assembling the basic editing experience from plugins.
That opinionated model is also the first buying decision. Helix's vision explicitly chooses consistent, memorable commands over shaving off keystrokes. A Vim user can recognize modal concepts but still has to rebuild muscle memory. The 2,013-file checkout contains about 109,176 lines of source, which helps explain why this is more than a small terminal binary. Give it a real editing session before replacing an established setup; reading the default keymap is not enough to know whether selection-first editing suits you.
Language servers are integrated but installed separately
The editor understands language-server messages without a plugin, and its documentation lists language configurations across a wide range of formats. That does not make each server part of Helix. You install the server for Rust, Python, C#, or another language yourself, make it visible on PATH, then use hx --health to inspect what Helix found. Syntax highlighting, text objects, automatic indentation, formatters, debuggers, and language servers have separate availability, so support for a language is not one yes-or-no switch.
The README is direct about one gap: only some languages have indentation definitions. A current C# issue, #15913, reports completion and navigation working while diagnostics do not appear, despite the health command finding the server. That is one report rather than a verdict on all C# setups, but it shows why hx --health is only the start of validation. Our 9.4 MB checkout had a tests directory and 4 CI workflow files, yet the language stack still crosses process boundaries that an editor build cannot verify for you.
What happened when we ran it
Our sandbox installed Helix's 327 packages in 36 seconds at commit 079a789. Both later stages reached the 900-second ceiling: the build timed out, then the tests timed out in their own run. The build did not produce a success result, and the test run did not reach a count of passed or failed tests. Those are timeouts, not compiler or assertion failures.
The last test-log lines showed Rust syncing toolchain 1.90.0, downloading 6 components, and compiling helix-term plus indoc. Nothing in that tail names a broken dependency or failed test. In a fresh Debian container with 3 CPUs and 12 GB of RAM, the honest conclusion is limited: 900 seconds was insufficient for this checkout and command. A developer evaluating source changes should budget a longer first run or use a warmed Rust cache, then record the result rather than assuming eventual success.
Packaged installs avoid the source-build wait
Helix documents operating-system packages as the typical installation route. Its release archives contain the hx binary and a runtime directory. That directory is not optional packaging debris: Helix searches it for grammars, queries, themes, and other runtime data. Copy it to a supported location, or point HELIX_RUNTIME at it. A binary that starts while using mismatched or missing runtime files is not a clean installation, and hx --health is the quickest check.
Building the newest code has more moving pieces. Tree-sitter grammars are fetched and compiled, and issue #16212 reports a release source build stopping when one grammar repository could not be fetched. Our own build timed out after 900 seconds without showing that error, so the two findings should not be merged. The practical split is simple: use a distribution or release package to try the editor, and reserve a source build for contributors or users who need unreleased changes. No credentials or server account are required for ordinary editing.
Active development comes with a large triage queue
GitHub recorded 45,958 stars, 1,630 open issues and pull requests, and a last push on August 25, 2026. The combined count is not a bug total. Recent activity included fixes, feature work, and current bug reports, which is stronger health evidence than the age of one release tag. The latest release was 25.07.1, published July 18, 2025, to lower the GLIBC requirement of GitHub's release artifacts. Code activity continued well after that tag.
Open reports still deserve a look before standardizing an editor across a team. Issue #16042 describes a repeatable crash when opening a small Haskell file, and #16218 reports a Windows Terminal crash after copying from a scratch buffer. Both identify version 25.07.1 and specific environments; neither proves that every user will hit the fault. Combined with our 327-package install and two 900-second timeouts, they support a measured recommendation: trial the packaged editor on your actual languages and terminals before making its configuration the team default. Plugin-dependent users should wait for the extension story or stay with Neovim.