I’ve come to accept that I’m just a sucker for shiny nerd things. I use Rust, despite never having had a professional reason to use it in my life. I switched to Linux in my student years and I’ve never looked back since, even though it constantly breaks and I can’t get my Bluetooth headphones to connect. I have a split keyboard with home row mods set up because I read some random blog posts and it looked cool to me. I literally learned to program because I figured I should learn how to do more nerd stuff.
For text editors, though, I’ve mostly stuck with the rather casual choices of VS Code and IntelliJ (when someone’s given me the money for it). They work fine, and I know I should be happy with that, but in the back of my mind I still long for a more hipster alternative. It’s not worked out yet though, so let’s try Helix out and see whether that fits the bill.
In this blog post, I’ll go over my motivation for switching to Helix (beyond nerd street cred), how that panned out, what the downsides were, and why I’ve stuck with it and will probably be using Helix as my main text editor for the foreseeable future.
Helix is a modal terminal editor with a focus on good defaults and a selection-first action model. There are a few things to unpack there:
Modal editing is where you interact with the code in multiple modes — typically, pressing a key in one mode will allow you to manipulate the contents of the document (manipulating selections, duplicating text, moving text around, etc), whereas pressing the same key in a different mode will simply type the character. This adds some complexity (you now need to juggle different modes of editing), but also makes it easier to use powerful text manipulation commands in a consistent way.
A terminal editor is one where all of the UI elements get rendered as characters in a terminal window. In many ways, it’s the same as a normal GUI, just instead of drawing arbitrary pixels, you’re instead drawing characters. This is typically a lot easier than full GUI rendering, and can be used in more places (such as over SSH), but it comes with its own downsides that I’ll talk about later.
By good defaults, I mean that Helix provides opportunities for configuration, but has defaults that are suitable for most situations. For example, a lot of languages these days provide a language server that can be used by text editors to provide autocomplete, jump-to-definition, documentation, and so on. If one of these servers is installed on your machine, Helix will try and use it out-of-the-box, no additional configuration needed. In this vein, a number of other features that would typically be plugins in other editors are included as part of the base editor with Helix.
The selection-first action model differentiates Helix from tools like Vim or Neovim (which are also modal terminal editors). The idea is that you perform actions, like the text-manipulation commands I mentioned earlier, first by selecting the region of text you want to act on, and then deciding what you want to do with that region. This is generally the opposite way round to how Vim and other similar editors do things, where normally you’ll choose an action, then say what you want to perform the action on.
None of the above is particularly new — modal terminal editors were some of the first visual editors around, and a lot of the success of VS Code comes from providing good defaults out of the box. The selection-first action model comes primarily from the Kakoune editor, and even Vim has a “visual mode” which works fairly similarly.
But Helix puts a lot of these pieces together in a single unit, and that’s what appealed to me, and made me want to try it out.
... continue reading