DEV Community

Cover image for Helix Editor: a matter of questionable existence
Yappaholic The Junior
Yappaholic The Junior

Posted on

Helix Editor: a matter of questionable existence

As a learning junior dev, I went from the depiction of soyest dev imaginable(python my beloved, windows and VS Code) to the true struggle and learning enjoyer(Neovim btw, Arch btw and Typescript(bearable)). So recently I landed my vim-motions on the helix editor to try and figure out: was it really necessary for helix to exist or should you try it out as a vimmer?

Prelude

From the start we should talk about the origins of the helix editor. Just as JavaScript came from Java, Helix came from Kakoune. What is Kakoune you ask? I have no idea, neither should you. All you should know is that Helix has a lot of similarities of vim and vim-motions but then it takes a rather strange approach to solve same problems. Let's take a look.

Selection over action

You heard it right. No more double y to copy line or double d(eez nuts) to delete line, Helix thinks otherwise. First you gotta select a line and then manipulate it. You think "Okay, just let me use visual block with V" and you wrong again. No more visual blocks, it's a matter of the past, now you need to use x to select line and x again to move one line down.

Okay, maybe I can start selecting at the start of the line and then use 0 to go to the end of the line, right? Right?

Image description

Sike! Helix thinks you are lazy to learn vim bindings, so now movement is bound to "go to"(or g) movement. To go to the end of the file, use ge and to select a line and go up you need to use vglk, when in vim you can just do Vk. Do you feel post-modernity yet? If not, then we go deeper.

Plugin system

Just as PlayStation 5 has no games, Helix editor has no plugin system yet. They are going to implement it using Lisp language and connecting it to Rust with some Steel plugin(did I mention it is written in Rust?) which is old and not post-modern at all. Forget about git with fugitive, forget about managing files with oil(also at the moment there is no file traversal in Helix except :open command and fuzzy finder), and the most important, no more file harpooning.

Instead, Helix comes with a lot of built-in stuff like fuzzy finder, tree-sitter, autocompletion, key bindings helper, diagnostics and lsp support when you install a correct language server. It is enough to make editor work with code but not enough to make it a complete IDE-like editor, so to get the most out of it modding community should do a lot of heavy lifting.

Too much FZF

Working with Helix feels kind of okay. You got most of the stuff done, autocompletion is snappy, files open a bit faster, but then you notice: there is too much fuzzy finder! Literally, it makes a lot of stuff. Diagnostics? FZF. File picker? FZF. Tree-sitter objects? FZF. Special names in the code? FZF. Hotel? FZF. Brazil? Mentioned.

Don't get me wrong, I think that fuzzy finder is awesome, but it has it's own caveats and is some cases it's better to use something else. For example, you can't really manipulate folders and files with FZF and when(as I understand) using FZF it goes through every folder no matter what you want to search and shows everything. That's when you want to search for something and get a screamer with all node_modules files. Yuck!

Configuration

Configs for Helix are written in .toml format, which is still better than some other options available(talking about you, Δ΄SON). Some terminal emulators and bun runtime also use toml to configure settings so you can get comfortable, and documentation covers enough settings to make experience personal and comfortable(no plugins tho).

"Post-modern" editor

Image description

At the end, Helix Editor is a sort of chimera from scrapped vim-motions, LSP, Tree-sitter, FZF and some other popular plugins from vim.

The main reason I don't like Helix isn't because there are no plugins, even though the version number is almost close to the one in emacs, but because of the motions. Vim-motions are designed with idea of mnemonics and being fast. When vim's g is responsible for many movements it makes sense, because it is short to "go". So G is going to the end, gg is going to the start, gf is to go to the closest matching character(the only gf you'll have), gd is to go to the declaration and so on. In Helix it is scattered everywhere and g is more like a leader key for other keys, so now you gotta make more hand movement and keystrokes. Just why? This is why sometimes it is better to stick with old ways, even when they are old. And also text wrapping is awful, just going to leave it there, think for yourself at least once.

So that's my thoughts about Helix Editor. Stay tuned to see how I test warp terminal to save you a couple of keystrokes, like a GigaChad.

Top comments (0)