I’ve been using this editor (and only this editor) since February. Decided to give it a shot for a few days after ~20 years in Vim, and it just kind of stuck. I honestly don’t think I’ve opened Vim since.
If a fast modal editor is your thing, then I recommend giving it a shot.
“wow” indeed! I was skeptical, as a Neovim user, but Helix really does feel significantly faster, from a brief experiment. I’m curious how much of this is due to design/a clean-slate codebase without Vim’s legacy, and how much is due to all “plugins” being truly built in (rather than just Lua that ships with the editor). And how much is perceptual due to e.g. having fewer “flashes” in the UI (Vim/Neovim tend to flicker when updating floating windows, etc.).
How long did it take you to get used to the differences between Helix and vim? Also are there any packages you miss?
Helix looks nice and looks like it has most/all of the main features I would want. I haven’t tried non-vim compatible editors because having access to random vim packages can be really nice. But also, my current neovim set up is a headache to get all set up and running (although, I am not sure how much of that would be fixed by this editor).
I don’t recall tbh. The only thing that I ever really found difficult was this thing of constantly being in visual mode. I still occasionally mess that up, but eh.. just a quick undo and that’s that.
I never was big on plugins, but sometimes I’d like a good file tree viewer when exploring a new project.
Mostly off-topic, but: historically, users have had strong personal preferences around package management in Vim/Neovim. This combined with the lack of a package specification standard/central package repository is (educated guess) why there’s no “full” package manager built-in, though the (semi-recent, Vim 8) native packages manager provides some of this functionality (e.g. basic loading control, though no downloading, updating, lazy-loading, etc.).
I’d also note that I would not advocate for packer, specifically, being built-in (at least in its current state). It’s too opinionated and does too many things that not all users will want/need. I think there’s a better argument to be made for integrating something simpler that can implement the bare-bones operations (e.g. git stuff, loading primitives, etc.), and which other package managers can build off of (similar to how the built-in LSP functionality is designed).
Did you set it up with something like helix-vim? I can’t see the rationale in learning a new set of keymaps for commands I have ‘baked in’ I have enough trouble with the little differences between neo-vim/vim/vscode-vim emulation.
For me it was mostly curiosity, and maybe a feeling that I/we spend a lot of time fighting something (legacy?) that we really shouldn’t have to fight with.
Helix has amazing discoverability and the key bindings make sense, but it’ll take a bit to learn of course. The biggest one for me, was to stop using x and just always use d.
To me, just trying it again now, it’s that I hit dd to delete lines reflexively, use ciw to change inside a word a lot and hit x to delete. That entire trio of ops doesn’t work. helix-vim is just a repo with a premade config file to get helix back closer to vim: https://github.com/LGUG2Z/helix-vim
Trying it now it seems to fix x and dd but ciw doesn’t work, there’s some commentary on the page there on c taking extra configuration to make work. I do like the speed of helix, and it feels like a contender (especially if language server support gets really easy).
Helix is a bit different that way. I’m not sure you’re going to have a good time if you want it to behave like Vim.
If you take ciw (which is imo one of vim’s most powerful things), then the mindset is that you select first (so, the iw part), and then what action you want to perform (the c). Pressing iw won’t work though, you’ll just insert a “w” where your cursor is. Instead, hit m (for “mark”) and read the little popup. i is what you want, which gives you another popup thing, where you can find w. So the sequence becomes miwc.
A, perhaps, better way to do this, is to realize that a word is the “next ast node up” from where my cursor is. Tree Sitter is a beast that I’m still exploring, but play with Alt-Up and Alt-Down (or Alt-o / Alt-i). You’ll see you can then just do Alt-Up c instead of ciw. It is really quite powerful.
Hmm, now you’ve piqued my interest considerably in 1 paragraph. This feels (a) discoverable once you see how helix is working and see that it has popups (b) an actual new thing (as opposed to vi/vim features under a different keymap). Nice, I like this.
[edit] note that helix-vim steamrolls some of this interesting stuff, so I’m going to try vanilla helix to see if I can take advantage of its “stock” differences
I think I’d seen the initial announcement and thought, ok rethought out vim. Yesterday we had a power outage and I ran hx --tutor which is essentially how I learned emacs then vim back in the day. With the power out I didn’t have time to install the language server support, but I think overall helix makes sense as a rethinking of modal editing, and not a ‘remapping’ of vi/vim standards.
It looks similar to Kakoune, which I recently started using to try and get some of my coding workflow out of VS Codium and into a terminal. Can anyone compare/contrast Helix vs Kakoune? The homepage says it was heavily inspired by Kakoune’s design, but I’m curious why I’d pick Helix over Kakoune.
I can speak to this a little. I’m a kakoune user who tried helix for a day or two. Helix is a more batteries-included editor. It incorporates LSP support into the editor itself instead of implementing it as a plugin (which kakoune does). It uses tree-sitter for syntax highlighting, which is more accurate than kakoune’s regex-based approach. It also is slightly more discoverable than kakoune, as pressing spacebar opens a command palette that eagerly tries to teach you all of the features. It’s written in Rust, and it works well on Windows (where kakoune struggles both in WSL and Cygwin).
However, I’m sticking with kakoune. I like the low dependency footprint (only a C++ compiler and stdlib at this point), fast build time, client-server architecture, easy extensibility, public domain licensing, and minimal design. Kakoune lets me plug it into my environment in a way of my choosing and wire it into my tools how I’d like. Helix is a more conventional editor with it’s own internal windowing, file browsing, etc. None of that is inherently bad, but I prefer the kakoune approach. YMMV.
Adding to the other comment: Helix’s default keymap actually slightly walks back on Kakoune’s one, I’ve had to bind some keys to get more selection operations in normal mode instead of select mode and make it more Kakoune-like
Great editor, instead of going through massive config hell like with vim/neovim and installing tons of plugins, it just has all i need from the get-go.
Thanks for the great release. Gave me a reason to update my terminal emulator code for the embedded editor terminal in my email client! Now it fully supports hx.
I’ve been using this editor (and only this editor) since February. Decided to give it a shot for a few days after ~20 years in Vim, and it just kind of stuck. I honestly don’t think I’ve opened Vim since.
If a fast modal editor is your thing, then I recommend giving it a shot.
I didn’t think “fast” mattered, but I installed it and…WOW! yeah, fast matters
“wow” indeed! I was skeptical, as a Neovim user, but Helix really does feel significantly faster, from a brief experiment. I’m curious how much of this is due to design/a clean-slate codebase without Vim’s legacy, and how much is due to all “plugins” being truly built in (rather than just Lua that ships with the editor). And how much is perceptual due to e.g. having fewer “flashes” in the UI (Vim/Neovim tend to flicker when updating floating windows, etc.).
That’s why I was stuck in Vim for 20 years :D
How long did it take you to get used to the differences between Helix and vim? Also are there any packages you miss?
Helix looks nice and looks like it has most/all of the main features I would want. I haven’t tried non-vim compatible editors because having access to random vim packages can be really nice. But also, my current neovim set up is a headache to get all set up and running (although, I am not sure how much of that would be fixed by this editor).
I don’t recall tbh. The only thing that I ever really found difficult was this thing of constantly being in visual mode. I still occasionally mess that up, but eh.. just a quick undo and that’s that.
I never was big on plugins, but sometimes I’d like a good file tree viewer when exploring a new project.
I appreciate the reply, thanks!
Had a look at my plugins. I’d forgotten I used neovim, and that Lua is awesome. My plugins are
space-gand]dand[dnow. Works fine.gwas the letter for the diagnostics viewer, so I hitspaceand it tells me.Mostly off-topic, but: historically, users have had strong personal preferences around package management in Vim/Neovim. This combined with the lack of a package specification standard/central package repository is (educated guess) why there’s no “full” package manager built-in, though the (semi-recent, Vim 8) native packages manager provides some of this functionality (e.g. basic loading control, though no downloading, updating, lazy-loading, etc.).
I’d also note that I would not advocate for
packer, specifically, being built-in (at least in its current state). It’s too opinionated and does too many things that not all users will want/need. I think there’s a better argument to be made for integrating something simpler that can implement the bare-bones operations (e.g.gitstuff, loading primitives, etc.), and which other package managers can build off of (similar to how the built-in LSP functionality is designed).Did you set it up with something like helix-vim? I can’t see the rationale in learning a new set of keymaps for commands I have ‘baked in’ I have enough trouble with the little differences between neo-vim/vim/vscode-vim emulation.
No. Don’t know what helix-vim is, sorry :)
For me it was mostly curiosity, and maybe a feeling that I/we spend a lot of time fighting something (legacy?) that we really shouldn’t have to fight with.
Helix has amazing discoverability and the key bindings make sense, but it’ll take a bit to learn of course. The biggest one for me, was to stop using
xand just always used.To me, just trying it again now, it’s that I hit
ddto delete lines reflexively, useciwto change inside a word a lot and hitxto delete. That entire trio of ops doesn’t work.helix-vimis just a repo with a premade config file to get helix back closer to vim: https://github.com/LGUG2Z/helix-vimTrying it now it seems to fix
xandddbutciwdoesn’t work, there’s some commentary on the page there onctaking extra configuration to make work. I do like the speed of helix, and it feels like a contender (especially if language server support gets really easy).Helix is a bit different that way. I’m not sure you’re going to have a good time if you want it to behave like Vim.
If you take
ciw(which is imo one of vim’s most powerful things), then the mindset is that you select first (so, theiwpart), and then what action you want to perform (thec). Pressingiwwon’t work though, you’ll just insert a “w” where your cursor is. Instead, hitm(for “mark”) and read the little popup.iis what you want, which gives you another popup thing, where you can findw. So the sequence becomesmiwc.A, perhaps, better way to do this, is to realize that a word is the “next ast node up” from where my cursor is. Tree Sitter is a beast that I’m still exploring, but play with
Alt-UpandAlt-Down(orAlt-o / Alt-i). You’ll see you can then just doAlt-Up cinstead ofciw. It is really quite powerful.Hmm, now you’ve piqued my interest considerably in 1 paragraph. This feels (a) discoverable once you see how helix is working and see that it has popups (b) an actual new thing (as opposed to vi/vim features under a different keymap). Nice, I like this.
[edit] note that helix-vim steamrolls some of this interesting stuff, so I’m going to try vanilla helix to see if I can take advantage of its “stock” differences
Happy to hear that! Have fun. I really think curiosity is the right approach :)
I think I’d seen the initial announcement and thought, ok rethought out vim. Yesterday we had a power outage and I ran
hx --tutorwhich is essentially how I learned emacs then vim back in the day. With the power out I didn’t have time to install the language server support, but I think overall helix makes sense as a rethinking of modal editing, and not a ‘remapping’ of vi/vim standards.helix-vim is interesting! I feel so seen by the README.
Same here. I use it quite a lot Once Debugging is well supported it will mean i will ditch VSCode for good. Really love Helix.
I’m curious about this. I don’t know VSCode very well; but what exactly is it you are missing? Setting breakpoints and such?
Edit: Just noticed Helix has experimental Debug features. I’ll explore those :)
It looks similar to Kakoune, which I recently started using to try and get some of my coding workflow out of VS Codium and into a terminal. Can anyone compare/contrast Helix vs Kakoune? The homepage says it was heavily inspired by Kakoune’s design, but I’m curious why I’d pick Helix over Kakoune.
I can speak to this a little. I’m a kakoune user who tried helix for a day or two. Helix is a more batteries-included editor. It incorporates LSP support into the editor itself instead of implementing it as a plugin (which kakoune does). It uses tree-sitter for syntax highlighting, which is more accurate than kakoune’s regex-based approach. It also is slightly more discoverable than kakoune, as pressing spacebar opens a command palette that eagerly tries to teach you all of the features. It’s written in Rust, and it works well on Windows (where kakoune struggles both in WSL and Cygwin).
However, I’m sticking with kakoune. I like the low dependency footprint (only a C++ compiler and stdlib at this point), fast build time, client-server architecture, easy extensibility, public domain licensing, and minimal design. Kakoune lets me plug it into my environment in a way of my choosing and wire it into my tools how I’d like. Helix is a more conventional editor with it’s own internal windowing, file browsing, etc. None of that is inherently bad, but I prefer the kakoune approach. YMMV.
Adding to the other comment: Helix’s default keymap actually slightly walks back on Kakoune’s one, I’ve had to bind some keys to get more selection operations in normal mode instead of select mode and make it more Kakoune-like
Great editor, instead of going through massive config hell like with vim/neovim and installing tons of plugins, it just has all i need from the get-go.
Thanks for the great release. Gave me a reason to update my terminal emulator code for the embedded editor terminal in my email client! Now it fully supports hx.