A Review of Helix after 1.5 Years
84 points by KnorrFG
84 points by KnorrFG
Honestly, Helix is such a great editor. I really hope the plugin system thing works out for them. I heard people are a bit divided on it, and there’s a non-zero chance it just won’t stick the landing.
Going for a Scheme-based plugin language is a bold move, but I honestly like it. It will make Helix feel like a modern synthesis of vim and emacs.
Agreed.
I haven’t even given it a try yet because of the plugin system. I wouldn’t use an editor without a well-designed plugin system that’s been around for a while
In the long run Helix could probably adopt CSTML so that its plugin architecture could closely mirror that of a web browser (another well-known system for live-editing documents)
@KnorrFG nice article, I’ve been meaning to try Helix myself.
I couldn’t find an Atom/RSS feed to subscribe to your blog, do you have one and it is just not linked on the front page (in a way my feed reader would automatically find)?
Hey, thank you. I’m afraid I don’t have one. This is the first time someone ever wanted one :) I’ll take that as a reason to add it. Although it might take me a couple of weeks.
I found this link to be a good reference for getting started from scratch: https://www.rssboard.org/rss-specification
This was great read. A couple of things stood out:
The fact that Helix just works with about every language (if that language has a good language server) is its biggest strength in my opinion.
This is one of the biggest weaknesses for me. I often find myself working with languages that have no good LSP or treesitter support. These are just not supported in Helix, but in other editors you can still define functionality and syntax highlighting for them.
Maybe you want to filter by error code? Also, easy. Just type a percent sign followed by enough letters to unambiguously define the column name, a space and then the value filter.
I am used to filtering everything like it describes, but first class support for columns is new to me. That is really powerful.
I’ve often read the opinion that this key map is more effective, but I can’t agree with that. Granted, it’s a little more intuitive for users new to modal editing. However, in general the key maps are pretty similar, and it didn’t take me more than a week to get used to it.
I find that a really interesting take, given how much praise the kakoune model usually gets. It makes me think of this why not kakoune argument about why the vim modal editing is actually better.
I really hope the plugin system works out well for them. At this point I don’t think I could use anything that is not highly extensible. My Emacs config is over 1500 lines. But different strokes for different folks.
This is one of the biggest weaknesses for me. I often find myself working with languages that have no good LSP or treesitter support. These are just not supported in Helix, but in other editors you can still define functionality and syntax highlighting for them.
LSP is really just a nice to have.
I haven’t been using (neo)Vim for more than 6 years now, but back then it was very laggy precisely because syntax highlighting was regex-based, so on some files it could not keep up with editing. Turning :syntax off IIRC made editing smooth. That was one of the main reasons why I switched to Kakoune, and later Helix.
So I think it’s much better to invest in a treesitter support once for languages you care about, that potentially benefits all the text editors (and other tools), than hoping for half-assed solutions in every single piece of software. Obviously you personally might not want to/be able to do that effort, but in principle it’s just much more scalable solution. If you ask me any language/DSL/text format that has any traction should come with official LSP and TreeSitter. Many nice programming languages that are being built now start with these (example: Gleam), and thank to that they start with great UX in many text editor which puts them on equal footing to more established languages.
The half-assed approach works, to some degree, with context sensitive grammars. It’s a hack, but that’s something the TS parsers won’t do.
Helix is amazing. After switching from NeoVim, I haven’t looked back, Helix become my daily driver.
I like Helix a lot. It’s well-designed and I use it here and there. However, I realized that the reason I’ve stuck to Vim so tightly all these years is that everything else has a Vim mode. I hardly ever use actual Vim (or Neovim) except to make quick edits (and Vimwiki) and I have definitely moved a lot of those quick edits over to Helix. But I doubt I’ll ever be terribly proficient with Helix unless JetBrains gets a Helix mode :-)
Me too, but for VSCode.
It makes me wish there was something like LSP but for keyboards. Imagine if there only had to be one implementation of vim or helix or eMacs mode instead of one for every editor
Take a look at https://github.com/71/dance/
It’s focused on Kakoune bindings, but some form of Helix bindings was just merged into main (so, probably not on VSCode marketplace yet).
There is also an older dance-based Helix VSCode extension, I believe.
My concern with these plugins is that except for big ones like Vim and Emacs they eventually they become unmaintained, they’re partially implemented, or they end up deviating from their inspriration in a way that makes consulting the reference docs unreliable.
But I don’t want to prejudge this one, I’ll take a look at it - thanks
Is the focus on consistent keybindings with modal editing, or are you just looking for something consistent? One could argue that IBM Common User Access is pretty common, and that that mixes better when the keybindings that Emacs has. So if you’re not searching for modal editing in specific, why not prefer emacs everywhere? Since readline has nowhere to show the mode, modal editing is disadvantaged on a command line.
I just already know Vim bindings, plus it’s available basically everywhere (even Xcode has a plugin for the once a year I have to look at iOS code). I do like modal editing, though, which is why I originally learned how to use Vim. I don’t use anything fancy at the command line, though, other than some of the Emacs-isms that macOS ships with (C-a, C-e, C-k).
This has encouraged me to give Helix another shot. I’m really excited for the future of the plugin system.
I’d really like something equivalent to vims compiler feature, so I can quickly run pytest / mypy or other things against a file. Would be nice to fill in the gaps for languages where the linting / type-checking tooling predates LSP.
For cases like these, you can create a project wide config (create it at $project_root/.helix/config.toml) and add keybindings using the macro keybindings and the shell command.
Disclaimer: I haven’t done this myself before, and don’t know how well it works.
Nice, I’ll check it out.
It looks like the :sh command line parsing was recently improved to expand %{buffer_name} to the current file. Which is basically what I need!
Re. the position of escape, Bill Joy was using an ADM-3A when he wrote vi and csh. Its keyboard layout is where the vi hjkl motion commands came from, and the shell abbreviation ~ for $HOME. It has ctrl in the correct location next to A, and esc next to Q. I don’t know of any classic keyboards with esc next to A.
Nice read 👍. Something I was looking for in a while.
I am at a point where I might not have enough time to relearn the whole modal movements but I still occasionally dabble in helix. I like how it’s evilving. I have a feeling that I will eventually switch because I only need the minimum functionalities but with lsp integration and that works nicely. I use Jetbrains for work as it would involve heavy usage of debuggers and refactoring, which I don’t get out of the box in other places and hence I pay for it.
Helix reminds me of a saying I once heard: “the first examples of a superior principle are worse than the last examples of an inferior principle.”
I’ve tried to use it a few times and I can tell that noun-verb with multiselection is just so much better than verb-noun! But it’s also missing critical things I need like a scripting system (which is different from a plugin system!) and autocommands. I’m hopeful that eventually it’ll be something that can replace Neovim for me! Or that someone will make a complete noun-verb system for neovim that’s close enough.
Helix is on my list of “Awesome Zero Config” [1], tools that work out of the box without needing lots of config to make it usable.
Great editor all in all, although the treesitter-heavy editing idea makes it awkward to edit files when there is no grammar. I ran into this with Lex and Yacc files, had to switch to Vim for that.
I’ve tried Helix, 2-3 times over the years, and each time has made me realize how much I’ve come to rely on my plugins. Hopefully they manage to get it implemented and I’ll be happy to try it again..
But in that time, the Neovim plugins have been getting better and better too. If you stick to the popular ones, they are really rock solid. I fear that even with a plugin system, the Helix community is going to have a lot of catching up to do before I’d consider switching for good.
Great write up, I learned a thing or two and I’ve been using Helix for over 2 years now :)
Good review - this is very close to my experience after 4 months of daily usage, coming from vim. Ignoring decades of muscle memory was surprisingly easy and Helix’ consistency makes it a joy to use.
Thank you for mentioning the new file browser functionality. A (minimal) netrw-like interface was the only function I really missed.
I’ve made the switch to Helix at roughly the same time. I’m also pretty happy with it (for example, I was able to live-code a semantic search in just a bit over half an hour in Rust). And I’m not even using all of the functionality (nor did I know that e.g. there were multiple file pickers – that’s nifty!).