I’ve been using Helix for roughly 1.5 years now,
and for the latest release (25.01) I decided to summarized the thoughts I’ve
been collecting until now.
This article has first been released in the german IT-magazin Golem.
Link to article (paywalled)
Helix is a modal terminal editor, like Vim. That means you have multiple
modes, one of them dedicated to inserting text into a document (insert-mode)
and the others to modifying it in different ways, turning your keyboard into a
big game pad specialized in text editing (the default mode of those is called
normal-mode). Before I started using Helix, I’ve been using Vim for a good 7
years, and I want to provide a comparison of these two.
Helix core is much more powerfull than Vim, but since there is no plugin system (yet), there
is functionality that vim can acquire through plugins, that Helix does not have.
The upside is, that you basically don’t need to configure Helix.
My last Vim config was roughly 100 lines of Vim-script + 500 lines of Lua.
My Helix config is 30 lines of toml, and 3/4 of that are keybindings I added
to address Vim habbits.
A lot of things that require plugins in Vim like autojump,
file-pickers, language server support, etc. are built right in and just
work. My mind was blown when I opened the editor for the first time in a rust project
and was immediately able to use rust-analyzer, without adding a single line of config.
Getting into using a modal editor when you come from something like
VSCode is hard, but it’s worth the effort. Helpfully, Helix has
a built-in tutorial. After opening it you can type :tutor and a
text file is opened that contains an interactive tutorial. You can quit
Helix by typing :q!, in normal mode btw. If you’re not in normal mode,
you typically get there by pressing Esc
A Tour of Helix
First let me show you a selection of the things Helix can do out of the box,
without plugins and without configuration
The File-Picker
I think having a file picker is central in an editor. And I don’t mean a file tree,
but a picker. Let me show you:
This gives you access to all files of the current project. Helix will look for the
project root by searching for a .git directory or one of multiple language dependant
files that typically are in a projects root, and show all files that are within this
root. The picker gives you a fuzzy search, but can also understand
regex. Did you type a filename to then realize it exists multiple times within
different directories? Just add the directory afterwards with a space:
Do you want a list of all toml files in a project? Just use regex and type
toml$:
There are multiple file pickers. You can open the picker in the project root,
in the working directory in which you started Helix, in the directory
which contains the file you’re currently editing (although the last one
requires you to define a custom hotkey), or in the root but only shows
those files that are not clean according to git.
You can also move the selection in the file-picker by using
uninitiated: this means Control + n) and
Overall the picker is pretty powerful, but some people just prefer a file tree.
This has arrived a couple of days ago in the latest master. Building Helix from source
is quite easy, and I’ve never had a problem using the master branch, but if you are
not comfortable doing so, just know that you will have a file tree from
the next release on.
LSP integration
Helix primary view on code is defined by two things: The language server
protocol and the treesitter. There is a huge list of supported languages and if
you use one of those languages, Helix will just work with the standard tooling
for that language. If you want to use something that’s not supported instead,
you can add a treesitter grammar and a language server config, and you’re
good to go. But most people will not need that. Helix even has support
for niche things like Justfiles,
cabal config and Elvish.
The fact that Helix just works with about every language
(if that language has a good language serv
