I was totally impressed by helix. I would suggest anyone starting new to start with helix instead of vim/neovim.
Hopefully helix would have plug-in system in near future.
I tried it out really early on, and was quite impressed. Out of the box, it’s quite solid. Reminded me a lot of my modded Zsh setup, vs a completely stock Fish, that did all of the same and more. Unfortunately for a proper development environment, the lack of plugins is where it ended for me
The main killers for me were the lack of anything like the treesitter text subjects (contextual treesitter objects) the lack of anything like leap nvim. But it lets all the stuff that’s normally a bit of a headache to set up work out of the box.
Treesitter is now implemented. Setting up LSP was easier than in neovim. Now it feel fairly complete and ready for plugin system.
I’d tried a lot of vim alternatives, but helix was the first one that made me completely switch over.
Even without plugins it’s very much usable as a daily driver.
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.
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 happy with Kakoune, but when I start to want more, Helix is high on my of editors to learn.
In the blog post, the author mentions using shim programs to translate between things like tree sitter and kakoune, how many of these sort of things do you use in practice, is it difficult to manage them? The nice thing with neovim compared to a setup like this is that I don’t need anything installed aside from git and the editor itself.
I needed to install a plugin to select objects delimited by characters, which I infer provides some of the basic behavior of tree-sitter, but since I forget the details, I guess that means there’s no fiddling involved. Set it and forget it.
Kakoune has a welcoming and helpful community, so when I struggled to understand the basics of configuration and installing plugins, I got the help I needed. It’s been a few years since I needed help, so perhaps that means I’m not adventurous enough and perhaps that means everything has simply kept working with little maintenance.
I have vague memories of putting in effort to set things up, but evidently that didn’t traumatize me.
And just in case it’s helpful: https://github.com/phaazon/kak-tree-sitter
deleted by creator
Hadn’t tried it before, but went through the tutorial. Seems like a good editor; only modal editors for me, you know? :) I’ll probably stick with Vim for now, but it seems like something to watch.
Yeah I think since trying modal editors going back to GUI/Chorded Editors in a no go.
Honestly I can’t believe anyone uses a chorded editor? Am I just missing something or is it a lot of extra keys to press to achieve the same thing as a modal editor.
Memorizing chords is conceptually simpler than taking on a modal mindset. I sure got pissed at insert mode plenty of times while I was learning vim.
Thankfully this was during my college masochistically-acquiring-skills-that-make-me-feel-cool phase where I was also learning LaTeX, so I just focused on the future gainz. I’m so glad I did on both counts.
Weirdly I think Vim’s modal mindset is a much simpler grasp than the finger gymnastics presented by Emacs.
I sopped using EMACS because chording is horrible for RSI and carpal tunnel. Same reason I moved off kakoune (which the author of the article mentions frequently). Kakoune is heavily chorded.
Helix is nearly pure modal, except for basic shift and some simple alt chords: most mode sequences like m-, space-, etc bring up a context menu with next-key options for the mode; it’s fantastic for learning, and for remembering those things you use so rarely you never quite memorize them.
I suppose I don’t see what is conceptually challenging about chords; they’re just physically annoying and require memorization. Most people are used to control key chords at least, so emacs benefits from that. Whereas vim requires a deeper shift in thinking.
