The Blog of Bob Rubbens
Between December 2024 and early this year, I tried using Helix for a few weeks. It looked cool, and the batteries-included approach sounded attractive to me, as keeping my Vim setup up and running, and also enabling new language support in Vim, always felt tedious and brittle. Using Helix was generally pleasant, but ultimately I stopped using it because of a few annoyances and network effects. With the end of this year quickly approaching, I figured it’s about time to turn this small personal experiment into a blog post.
For a more general “let’s start using Helix” introduction, have a look at Jonathan’s post. If you want to decide whether Helix
Coming from Vim, using Helix is mostly a pleasant experience. I caught myself falling into the trap of letting my Vim muscle memory take over every once in a while. Whenever that happened, it did feel jarring. Luckily that didn’t cause me to quit early on, and it wasn’t too difficult to turn off my muscle memory after a few days of continued use.
The newest version wasn’t available via my package manager, but
compiling it myself and installing it locally was a breeze since I also
happened to have cargo installed. That’s on me - I’m on an
ancient Linux Mint distribution.
It feels like the Helix developers definitely give a high priority to user experience. An example for this are the helper panes that Helix provides in just the right places. For example, when you press space, a pane pops up that shows what keys you can press next, and their effects. I don’t think this is an original idea. I think this was first done by the Kakoune editor, though maybe they got it from somewhere too. In any case, it’s a great idea for making an editor interactively explorable, and it’s a feature that deserves being built into the editor from the start.
I found LSPs a bit tricky to set up, but that generally had little to do with Helix, and more with that often the available settings of LSPs were not easy to find (for someone who had never really used LSPs before). Though linking a few example configurations and maybe keeping those in a CI to keep an eye on if they ever stop working seems like a good idea to me. After setup, I loved using various LSPs through Helix’s uniform interface.
I never encountered any crashes from Helix, and the color scheme is great. It’s the one thing I stole for my Vim config! Also, I love the two-letter executable name.
The documentation is relatively complete for a new and in-development tool. It can be hard at times to, given a certain effect, find which key does that. Sounds like a great use case for a (locally executing) LLM. Other than that, there is plenty of introductory material to read about Helix. Whenever I caught myself having a gripe with how the keybindings did not achieve what I wanted, I could usually find existing discussions about the problem. These discussions also usually contained a satisfactory solution. There were a bunch of things I ran into, and most of them were easily resolved, but I didn’t document them all thoroughly, so I have only two examples in this category:
If I want to delete until the end of the current line, I usually type
D or C. I couldn’t find a similar key in the
Helix docs that would allow me to do this. After some searching on Kagi, I found a GitHub issue suggesting the
following combination as a replacement for Helix,
t<Ret>d:
t: extend current selection until you find…<Ret>: a newline,d: and delete the selection.It requires a bit of a change in perspective, but the combo works
perfectly. I also like the minimalist reuse of using
<Ret>to indicate the newline character. It’s however
quite a bit longer.
To delete the current line in Vim, I would type dd. In
Helix, usually xd is suggested:
x: quoting the Helix docs, “Select current line, if
already selected, extend to next line”,d: delete it.The downside is that it works a bit strangely in the edge case of an
empty line. In that case, the next line will also be selected. I’m not
entirely sure why this is. Maybe it makes x more composable
or more broadly useful in practice, as it allows repeatedly pressing
x to select more and more lines. In practice, I found it
counterintuitive, as it frequently broke my workflow when deleting
lines. The alternative that works more predictably is
Xd:
X: “Extend selection to line bounds (line-wise
selection)”,d: delete it.This more or less fixed the problem for me, with the only downside
being that I was sometimes repeatedly pressing X and
waiting for more lines to be selected, which of course never happened. I
guess the edge case that “on an empty line, immediately select the next
line as well” doesn’t fit into my brain in the short term. I don’t
really consider the design of x/X a downside,
I think I would’ve adapted just fine in the long term.
Let’s have a look at the things which I don’t think can be fixed by workarounds or adaption, but which are endemic to Helix’s focus on manipulating the current selection to get things done.
I want to briefly interject that I don’t think the below topics are huge problems, and I’m also not denying that Vim probably has 10 times more intricacies like this. But they would require a significant change both in my workflow and in way of thinking, and I think it’s a fair question to ask whether that’s worth it for me. For someone else, the answer might be different, as Helix does have a fair number of cool things going for it!
This is one of the concepts Helix is centred around. For me it was difficult to predict and remember which commands change or grow the selection, and which ones reset it. At times it even felt kind of random.
For example, sometimes I wanted to select a large chunk of text, so I
pressed x/X a bunch of times. It usually
overshoots, so by muscle memory I press k to adjust, and then the whole
selection disappears.
I had to learn to press v first when I anticipated such
a situation to come up, but I never quite got the hang of it. I felt
that it happened quite often that I thought, in hindsight, “oh yeah, I
should’ve pressed v a few seconds ago to avoid losing this
selection”, but by that time I already had to start over.
f/t for “getting
around”This sounds stupid, but I guess my brain is then just not the right fit for Helix: you have to think a lot before you type. Here, with “typing” I mean “issuing commands”. In Vim, I can usually just type in the direction I want to go, and fix up whatever I did wrong in terms of selection. I’ve found that, in Helix, for some use cases that feel natural to me in Vim, the Helix replacement just required me to do more upfront thinking.
Consider this example. Say you want to make a selection that ends at
“a”. In Vim, I’d type vfa. In Helix, it’s a tad shorter,
which is nice: either ta to select just before
“a”, and fa to select including “a”. Now here’s
the catch: with vfa, I can wiggle back and forth with
h and l depending on if I want to include “a”
or not, or perhaps want a few characters more or less. In Helix, if you
do that, the selection disappears.
Now, you might say: “you can just enable visual mode in Helix too,
then you can wiggle afterwards in Helix too!” And you’d be right. Now
this is where it gets a bit technical, but hear me out. The problem is
that in Helix, there is no cursor, there is only a permanent
1-character-wide selection that you control with hjkl.
Whenever you jump to the next word, e.g. using w, the word
you just jumped over gets selected. Because of this, if you press
v after w, the word you just selected is
included in the current selection. Meaning that the workaround we
started with causes extra stuff to get selected as a side-effect.
To work around the side-effects of the previous work-around,
we can clear the current selection using Alt-, to remove
the primary selection. There might be another key that reduces the
selection to one char, but at the moment I can’t find it quickly in the
Helix docs, so let’s just assume this solves it.1
This makes the final combination for deleting up until or including a
character, including possibility for later wiggling, with all
workarounds: <Alt-,>vfa.
Another variation of this theme is when jumping to the next “a” just
because you want to type a bit somewhere near there. If you just do
fai, you will actually enter insertion mode at the point
where your cursor was before you typed fa! I’m not exactly
sure why this is, I guess because the anchor is left there when you type
fa; I’m sure there’s a good reason for it, I just don’t
remember. In any case, this means that you will need to type
faa, which is “find a, then enter insertion mode
after the selection”. And then you get into the edge case of
the previous example again: if your intention was to add some text after
“a”, this is perfect. If your intention was to remove “a” and type
something else, you actually should’ve typed taa, which is
“put the cursor just before a, and start typing just after the
selection”.
I hope you see the point I’m trying to make: for a few of these patterns which feel natural to me in Vim, the Helix replacement requires me to do more upfront thinking. As an aspiring grug-brained researcher/developer, that’s thinking time I’d rather spend on something else.
I think in terms of technical/usability problems, my situation with Helix was perfectly sustainable. Yeah, there were issues, but either they were resolved at rapid speed, had acceptable workarounds, or I felt like, given some time, I could adapt. What really killed Helix as a daily driver for me was the network effect of being able to use Vim everywhere.
I use Vim bindings where I can, for example, in IntelliJ, Obsidian, and even in Firefox. I wish TeXStudio had Vim bindings! As I was adapting my muscle memory to Helix, I noticed that friction began to appear when using these other programs. Naturally, if there had been a Helix mode, that could’ve been a good alternative. At the time of writing, at least for IntelliJ there seems to be some movement on this, so obviously this might change in the future. But the key point here is that it’s hard to have one set of keybindings that work for variety of programs. Even the fact that this is remotely possible for Vim is already astonishing if you think about it. Realizing this has been the most important reason for me to stop using Helix and get back on the (Neo)Vim train.
Another reason not to stay with Helix is that, likely, good features of Helix will be ported to Vim. Possibly through plugins, but still. As a practical example, after Helix I’ve switched to using AstroNvim as a daily driver. The most convincing reasons were:
helix-nvim
😄One feature that drew me to Helix early on was the interactive help capabilities. E.g. when you press spacebar, a little menu appears showing all the sensible keys you can press next, and their effects. There’s nothing stopping Vim from also having this:
I think, in the long term, all Good™ features of Helix will spread to the other editors, possibly first via plugins. AstroNvim seems like a good compromise in that direction for now. I used to be pretty opposed to plugins as I want my setup to be zero-hassle, but now with AstroNvim plugins work pretty much out of the box, so there is less work involved in having a few passive plugins in the background.
So, do I think you should switch to Helix?
Do switch to Helix if:
Try Helix if:
Avoid Helix if:
And if you’re looking for an alternative for (Neo)Vim because you don’t like managing the config, give AstroNvim a try.
Generated with BYOB.
License: CC-BY-SA.
This page is designed to last.
