I was reading some opinions and blogs about helix and thought it’s really cool, gave it a try, and almost immediately switched back to vim. It was the moment when I tried to use some regex substitution and as it turns out there are no regex matchgroup substitutions in helix. You can’t easily do stuff like replace all occurences of a pattern “firstword secontword: thirdword” with “thirdword - firstword” for example. At first I thought that I’m just new to this editor and don’t know how it’s done, then after searching for a while found that helix doesn’t try to implement things that can be done by external tools, and the way to go is pipe your selections (or entire buffer contents) to sed or awk or whatever and and read from their stdout back into your file (?).
So, while it feels more unix-way (why have regex substitutions when you can pipe into tools that already do this), I still like that vim has this builtin, it feels more integrated into the tool probably. At this point, if helix doesn’t want to implement things other tools can do, why even have regex search and select? This could be done by piping into grep as well, I think. Anyway, just my silly opinion and my experience with helix is that I can’t use it without regex match groups and substitutions and I’m too lazy to learn how to pipe into sed and do this properly in helix, and it feels natural to me that vim has this builtin with a great amount of advanced options and features.
Like, for example, in vim you can do regex searching and tell vim which part of the match should be your final selection. It’s incredible how powerful regexes in vim are.
For anyone who’s curious, this is the state of discussing this feature: https://github.com/helix-editor/helix/discussions/8572
I’m not an authority on the helix ethos, but I’ve contributed a bit and hung around long enough to have a good read on their stance on most topics. The project is still young and managing the growing pains of getting a lot of traction relatively early. I think the devs value keeping the maintenance footprint small to keep the project sustainable.
The philosophy of helix’s design is to be a more convenient kakoune, not necessarily a vim. vim is much more widely known, so that analogy springs up more often, but this idea of using piping out to an external command for most operations comes from kakoune.
For features that would introduce significant maintenance overhead, may jeopardize the performance of a more common workflow or where the design goals are still maturing, the team tends to push such suggestions toward being developed as plugins when that system is added. I get the impression that they see the value of this workflow, but would prefer to see it battle tested as a plugin first.
I’m surprised the author is both a long-time vim user and defends the idea that everything being built in to the editor and config being purely declarative as positives. In my mind, vim being as slim or bulky as I want it to is a strength, not a weakness, and its config being a full language (especially since neovim/lua) is a superpower. I’ve yet to have my config just randomly break in almost a decade of tweaking it from vim to neovim, across multiple distros and package managers, for what it’s worth.
Helix does look pretty intersting though, but man does the idea of relearning everything after how long it took me to build that vim muscle memory sound very daunting. vim bindings being available almost everywhere, including other editors, some websites and third party apps, and my browser as an extension, is also a big part of why I hesitate to even give it a try…
You can configure Helix to behave a lot more like vim quite easily, beyond the default keybinds which are already quite similar. You can even revert to vim-style normal/visual modes, rather than Helix’s “select by moving approach” if you really can’t stand that.
After being a vim then neovim user for many years, I fully made the switch to Helix, using some options from the config I linked, and there are only a few minor things I miss.
Yeah I agree NeoVim being extensible is wonderful, and I believe Helix has the goal of adding a plugin system. It’s also super lightweight while including a lot of these core features we see repeated in nearly every NeoVim setup, the kind of thing like LSP & Tree Sitter which shows up so often it begs the question: Should this be built into the editor.
I am also terrified of relearning all the minds after years of vim use, although a lot of the base bindings are the same or similar. I guess if I could relearn the system keyboard shortcuts when I switched OS I can do the same here.
Yeah, I won’t pretend like Neovim is perfect at all either. I do agree that setting up LSP & TreeSitter is needlessly convoluted as is. lspconfig+mason.nvim+mason-lspconfig+null-ls.nvim just to get a couple linters/formatters and decent completion… I’d love it if I could just open a file, and… it just… worked, you know.
That’s what config distributions like lunarvim are for
Yeah I’m guessing that’s Helix’s approach. Maybe the bind relearning is worth it or maybe it inspires NeoVim or other Vim-like editors to come with more of the consistently repeated stuff enabled by default.
I think Helix is nice for people who are starting out with an editor. I’m not using vim because I can configure the hell out and turn it into a full-blown IDE. vim isn’t my main editor. I am using vim keybindings because they are supported widely and that means I don’t have to remember any specifics of the actual editor I am using. For me, there is zero incentive to switch to Helix.
He was the writer of This Week in Neovim for a while. I think he might have been adding tons of plugins to his setup and not all of them were well maintained or behaved. I’ve been quick to drop plugins that break more than once or twice, and I’ve never really had issues with stuff breaking update to update. Plus with Lazy’s commit locking for plugins it’s easy to restore your config to a working state.
