I gave Helix a try the other day and really enjoyed the "feel" of things. I'm also generally impressed with their philosophy / approach, after having spent way too much time tuning my Neovim configuration. However, I ran into several blockers for it being my daily driver, I thought I'd share them:
1. It's generally janky whenever the language server is slow, in ways that Neovim is not. The most visible one of these is that completion does not take into account the characters that were typed between when the completion request started and when the completion was selected. For example, if I type "abc", and the LSP suggests "abcdef" after having only observed the "a" keystroke, Helix will end up with "abcdefbc" as the final output. This is annoying.
3. Helix doesn't detect the correct root for my language servers in my environment, and it doesn't seem to have any way to override the detected root. This means that have to start the editor in the directory that I intend to use as the root. This gets really problematic when I'm working across several languages.
The pace at which this editor is galloping forward is breathtaking.
3 years ago, Helix didn't exist, and today it has most of the features of Neovim PLUS Neovim's most popular plugins. All built on well-tested modular foundations such as the Ropey crate, instead of on 30 years of legacy cruft.
I’m really impressed by Helix and would love to use it, but re-wiring Vim muscle memory developed over a decade or using it feels such a pain. The problem is also not even that if I stop using Helix I’ll have to re-learn Vim bindings, but the fact that I also use Vim bindings whenever I open VSCode, too.
The subtle differences are both good (many things out of Vim work out of the box in Helix) and painful (the ones that don’t give an awkward feeling.
Awkward take on that is that I think if Helix came up a completely different key bindings it would be easier to switch to…
> Awkward take on that is that I think if Helix came up a completely different key bindings it would be easier to switch to…
I'm still trying to use helix, as I think the design of the keyboard interaction is mostly an improvement on vi/vim. I think there are some shortcuts that helix stil need to "figure out" - like vim dd, for example (you can delete a line in helix, but you need something like xd. And xx won't work (because it "means" select line, expand to select next line).
And while one could of course remap helix, that would go against most of the benefits of changing imnho. In that case neovim would be more pragmatic.
My biggest pain point / muscle error from vim has turned out to be using x for delete - which surprised me a lot - if you'd asked me I'd probably said I delete with d in some combination or other. Apparently not.
The biggest benefit I see is the synergy between object/subject/selection -> action (wORD cHANGE) and the context menu on space (eg: x (select line) space (context menu) y (yank to system clipboard). It feels about as light as vim "leader", and really helps discovery.
Still not 100% sure I'll stick with it - but I definitely think helix have made a lot of good decisions.
The only ones that really trip me up are “x” and the surround ones. Not really too hard to overcome, in my opinion. Edit: I should also say that I’ve modified my Helix config quite a bit. You can find mine here: https://github.com/danieljaouen/dotfiles/blob/master/topics/...
I have recently made the switch from vscode to helix and after one day of struggle it has been a joy. The setup was simple and the overall design philosophy is great.
The main thing that is missing for me is a way to browse/move/copy/rename files. I still use vscode for those operations. I can understand that this is not the main focus of helix for the moment.
The deal-breaker for me is the switch from "procedural" action->movement to "objective" selection->action.
Just browsing the file feels dangerous, because when you press an action key by mistake, you cannot just cancel it with Esc, you need to undo the change.
At the same time, seems like because of the above, some selections are "disabled", e.g. in Vim to delete to last line is just `dG` (and the cursor doesn't move), here you need to explicitly go into visual mode, jump to the end of file and then delete, what will bring you back to where you started.
Well it's similar in vim: if I press `d` accidentally and I don't notice, then any subsequent movement commands will start to modify the file. It's a bit more explicit in Helix since you'll see a visual selection being made. Luckily in both editors you can undo the change :)
I don't really disagree that there's a big difference to vim (if not I don't think I'd find interesting, at the same time it can be painful) - but for what it is worth - there's a "view" minor mode:
As for select->act, I think this is (probably) worth it for the gain in discoverability (mainly from (any) select - then space for context menu/help).
And while you're right that helix is much more visual select-to-end-of-file;delete - is just vged. Personally I still think there might be need for some "quicker" actions, like dG or dd an yy - but it's not obvious how they would fit with the "good parts" of helix.
Maybe via a prefix-like command in normal-mode, eg: ",d" for "delete line"?
Non modal editors have a different type of danger. If you accidentally press a space at the beginning of a line in a Python file, you'll get an IndentationError when running it. If you press a d somewhere in any programming language you likely get a syntax error or a bad identifier.
Of course you have to save to file before those errors become real. Apparently Helix autosaves when losing focus, which is quite dangerous IMHO: accidental mistakes and code left unfinished when switching to another window to do anything. I prefer to save when I want to save.
woot super excited for this!!! I don't know what to say other than I fell inlove with helix when I first discovered it here on HN a couple months ago. it allowed me to completely quit vscode whereas when I tried full on neovim/vim before I always found myself going back to vscode.
I really wish I could use helix bindings in vscode. Im currently using both helix and vscode with vim bindings and it isnt exactly optimal. Helixs style of bindings are neat and consisten enough that I imagine they will see much wider adoption in the future, but at the moment I still have to remember when to use 'dd' and when to use 'xd'.
The editor seems good as a modern vim replacement, but it's a shame it's lacking syntax coloring for some languages. For instance there seems to be none for Fortran. And creating what's necessary for tree-sitter seems much more complex than writing some regex for vim.
A tree-sitter grammar is slightly more complex but it has a bunch of benefits! Syntax highlighting is more correct, faster and a bunch of smart features like indentation and folding, bracket matching can be built on top of it.
biggest issue for me isn't just the selection->action framework, but that so many of the keys are completely different from vim, and no piece of documentation covers them. I tried using helix, but after searching for 5 minutes "how to do x in helix", I just gave up and went back to vim. I'm doing going to do a search for every operation.
I think if helix wants to get much wider adoption, they should seriously investigate making a keybinding that works as close to vim as physically possible. This is the biggest thing holding it back from taking over imo.
If the bindings were the same, then what's the point? We're not a "vim ported to rust", instead we got our own take on things. (from the vision doc: "Don't try to be everything for everyone. There are many great editors out there to choose from. Let's make Helix one of those great options, with its own take on things.")
> helix wants to get much wider adoption
I've stated this before: I just want to make a good editor that I like using daily. There's a growing community of users with similar preferences that are very happy with it, but I'm not aiming to corner the market -- this isn't a startup. Much in the same way as vim isn't trying to become more like VSCode to increase it's market share.
That said, thanks for giving it a try! For keybinds, we do have a couple of guides:
[+] [-] adamkf|3 years ago|reply
1. It's generally janky whenever the language server is slow, in ways that Neovim is not. The most visible one of these is that completion does not take into account the characters that were typed between when the completion request started and when the completion was selected. For example, if I type "abc", and the LSP suggests "abcdef" after having only observed the "a" keystroke, Helix will end up with "abcdefbc" as the final output. This is annoying.
2. The posted directions (https://github.com/helix-editor/helix/wiki/External-binary-f...) for configuring prettier didn't work, there are no error messages visible in any logs. I haven't had the bandwidth to dig into this yet.
3. Helix doesn't detect the correct root for my language servers in my environment, and it doesn't seem to have any way to override the detected root. This means that have to start the editor in the directory that I intend to use as the root. This gets really problematic when I'm working across several languages.
[+] [-] archseer|3 years ago|reply
3) There's also a discussion for this, we hoped to include it in this release but it's instead going to be in the next cycle (https://github.com/helix-editor/helix/pull/4439)
[+] [-] p-e-w|3 years ago|reply
3 years ago, Helix didn't exist, and today it has most of the features of Neovim PLUS Neovim's most popular plugins. All built on well-tested modular foundations such as the Ropey crate, instead of on 30 years of legacy cruft.
[+] [-] bfrog|3 years ago|reply
[+] [-] udkl|3 years ago|reply
[+] [-] kirillbobyrev|3 years ago|reply
The subtle differences are both good (many things out of Vim work out of the box in Helix) and painful (the ones that don’t give an awkward feeling.
Awkward take on that is that I think if Helix came up a completely different key bindings it would be easier to switch to…
Edit: the differences are not way too dramatic but slightly annoying since many of those are very frequent actions - https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...
[+] [-] e12e|3 years ago|reply
I'm still trying to use helix, as I think the design of the keyboard interaction is mostly an improvement on vi/vim. I think there are some shortcuts that helix stil need to "figure out" - like vim dd, for example (you can delete a line in helix, but you need something like xd. And xx won't work (because it "means" select line, expand to select next line).
And while one could of course remap helix, that would go against most of the benefits of changing imnho. In that case neovim would be more pragmatic.
My biggest pain point / muscle error from vim has turned out to be using x for delete - which surprised me a lot - if you'd asked me I'd probably said I delete with d in some combination or other. Apparently not.
The biggest benefit I see is the synergy between object/subject/selection -> action (wORD cHANGE) and the context menu on space (eg: x (select line) space (context menu) y (yank to system clipboard). It feels about as light as vim "leader", and really helps discovery.
Still not 100% sure I'll stick with it - but I definitely think helix have made a lot of good decisions.
[+] [-] djaouen|3 years ago|reply
[+] [-] sbergot|3 years ago|reply
The main thing that is missing for me is a way to browse/move/copy/rename files. I still use vscode for those operations. I can understand that this is not the main focus of helix for the moment.
[+] [-] conaclos|3 years ago|reply
[1] https://github.com/helix-editor/helix/issues/200
[+] [-] Jorengarenar|3 years ago|reply
Just browsing the file feels dangerous, because when you press an action key by mistake, you cannot just cancel it with Esc, you need to undo the change.
At the same time, seems like because of the above, some selections are "disabled", e.g. in Vim to delete to last line is just `dG` (and the cursor doesn't move), here you need to explicitly go into visual mode, jump to the end of file and then delete, what will bring you back to where you started.
[+] [-] archseer|3 years ago|reply
[+] [-] e12e|3 years ago|reply
https://docs.helix-editor.com/keymap.html#view-mode
As for select->act, I think this is (probably) worth it for the gain in discoverability (mainly from (any) select - then space for context menu/help).
And while you're right that helix is much more visual select-to-end-of-file;delete - is just vged. Personally I still think there might be need for some "quicker" actions, like dG or dd an yy - but it's not obvious how they would fit with the "good parts" of helix.
Maybe via a prefix-like command in normal-mode, eg: ",d" for "delete line"?
[+] [-] pmontra|3 years ago|reply
Of course you have to save to file before those errors become real. Apparently Helix autosaves when losing focus, which is quite dangerous IMHO: accidental mistakes and code left unfinished when switching to another window to do anything. I prefer to save when I want to save.
[+] [-] jalino23|3 years ago|reply
[+] [-] Fraterkes|3 years ago|reply
[+] [-] djaouen|3 years ago|reply
[1] https://github.com/danieljaouen/dotfiles/blob/master/topics/...
[+] [-] SxC97|3 years ago|reply
[+] [-] bondant|3 years ago|reply
[+] [-] archseer|3 years ago|reply
[+] [-] jarbus|3 years ago|reply
I think if helix wants to get much wider adoption, they should seriously investigate making a keybinding that works as close to vim as physically possible. This is the biggest thing holding it back from taking over imo.
[+] [-] archseer|3 years ago|reply
> helix wants to get much wider adoption
I've stated this before: I just want to make a good editor that I like using daily. There's a growing community of users with similar preferences that are very happy with it, but I'm not aiming to corner the market -- this isn't a startup. Much in the same way as vim isn't trying to become more like VSCode to increase it's market share.
That said, thanks for giving it a try! For keybinds, we do have a couple of guides:
- `hx --tutor` is the equivalent to vimtutor
- https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...
- Our Matrix chat is always happy to help with questions :)
[+] [-] transportheap|3 years ago|reply
[+] [-] e12e|3 years ago|reply
[+] [-] voxelghost|3 years ago|reply