TL;DR:

  • Helix is a terminal modal editor written in Rust — LSP support and Tree-sitter highlighting are built in, not plugged in
  • Uses a selection-first editing model (select, then act) rather than Vim’s action-first (verb, then motion) approach
  • No plugin system, which sounds like a limitation but in practice means it just works with zero configuration

Most developers who try Vim or Neovim fall into one of two camps. There are people who invest the time to configure it properly and come out the other side with a genuinely powerful setup. And there are people who spend a weekend fighting init.lua, give up, and go back to VS Code. Helix is for the second group — though the first group has been switching too.

Helix is a terminal-based modal editor written in Rust. It has full LSP integration, Tree-sitter syntax highlighting, multiple cursor support, and all the language-specific intelligence you’d expect from a modern editor. What it doesn’t have is a plugin system. Everything is built in from the start.

The selection-first model

If you come from Vim, the biggest adjustment is the editing model. Vim is action-first: you think “delete word” and type dw — verb then motion. Helix flips this. You select first, then act.

So to delete a word, you press w to select the word, then d to delete the selection. To change a function argument, you press mi( to select inside the parentheses, then c to change it. The cursor is always showing you what you have selected, so you can see what’s going to happen before you commit.

This sounds like a minor detail but it changes how you think about editing. In Vim you have to mentally construct the operation before you type it and then watch it execute. In Helix the selection is the feedback loop — you can see if you’ve got the right thing before you modify it. For complex text manipulation this is noticeably less error-prone.

The model is borrowed from Kakoune, another modal editor that never quite broke through to mainstream use. Helix takes the same core idea and builds a more complete, more accessible editor around it.

Multiple cursors, not macros

One of Helix’s most useful features is multiple cursors, and unlike Vim where multi-cursor requires a plugin, it’s a first-class feature in Helix.

Press C to duplicate the cursor to the next matching line, or use a regex to select all occurrences of something across the file. You end up with multiple cursors that all respond to editing commands simultaneously. It’s faster than a macro for many repetitive transformations and more readable because you can see all your cursors before you start editing.

For example, to add a trailing comma to every line in a block:

  1. Select the block with x (line selection) then extend with X
  2. gl to jump each cursor to the end of its line
  3. a, to append a comma after each cursor

Takes about three seconds once you have the muscle memory. Equivalent to a carefully written macro in Vim, but you see what’s happening at each step.

Built-in LSP — actually built in

Neovim has excellent LSP support, but getting it working requires configuring nvim-lspconfig (or similar), installing language servers separately, and then debugging when the language server doesn’t attach correctly or shows errors in the wrong place. For Rust you need rust-analyzer; for Python you need pyright or pylsp; for TypeScript you need typescript-language-server. And then your init.lua needs to know about all of them.

Helix manages language servers automatically. When you open a file, Helix looks at the file type, consults its language configuration, and connects to the appropriate language server if one is installed on your system. You don’t configure this in Helix — you just install the language servers you want (rust-analyzer for Rust, pyright for Python, etc.) and Helix finds them.

The 2026 versions have brought sub-20ms LSP response latency for most operations, which makes code completion and hover documentation feel genuinely instant rather than slightly laggy.

Tree-sitter syntax highlighting is also built in and covers every mainstream language. The highlighting is more accurate than regex-based highlighting because Tree-sitter actually parses the file into a syntax tree — it handles nested structures, edge cases, and multi-line constructs that regex-based highlighters get wrong.

The no-plugin philosophy

Helix doesn’t have a plugin system. This is the thing most people find off-putting when they first encounter it. How do you customise it? How do you add features?

The answer is that you mostly don’t need to, which is both the strength and the honest limitation of the design. The features Helix ships with — LSP, Tree-sitter, multiple cursors, fuzzy file finding, git gutter, diagnostics — cover what most developers do most of the time. The configuration is straightforward: a TOML file for keybindings, theme, and editor settings.

What you can’t do is add arbitrary new features through plugins. You can’t install something like Neovim’s oil.nvim for file management in a split, or a custom status line plugin, or anything that requires running external code. If you want those things, Neovim’s ecosystem is genuinely richer.

The trade-off is that Helix installs in seconds and works immediately. Paste hx . into a directory and you have a working editor with language intelligence, no config needed. For developers who want to spend time coding rather than configuring their environment, this matters.

Getting started

Install Helix from your package manager — it’s in Homebrew, the Arch AUR, and various Linux repos, or you can build from source. Run hx --tutor to get an interactive tutorial that takes about 20 minutes.

The keybindings take about a week to build muscle memory for. The selection-first model feels strange for the first few sessions if you’re coming from Vim. After that it tends to feel natural, and going back to Vim’s action-first model starts to feel slightly backwards.

For configuration, start with just the theme: hx ~/.config/helix/config.toml and add theme = "gruvbox_dark_hard" or whichever suits you. Everything else can wait until you’ve used the defaults long enough to know what you want to change.