Helix 22.12
helix-editor.com
helix-editor.com
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.
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)
FYI your github link in your opencollective [0] profile seems to be wrong?
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.
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...
Maybe my biggest point is the difference in Vim integrations in IDEs vs using Helix outside of that, so not sure if I should switch but maybe I'm just being too lazy.
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 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.
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.
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"?
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.
[1] https://github.com/danieljaouen/dotfiles/blob/master/topics/...
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.
> 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 :)
What I wanted to say, was that helix should make an additional keymapping file that has nearly identical keys to vim. Repositories like gitui [0] do this, so vim users can just jump in guns-blazing. Granted, they have far less keybinds to cover.
The second link, "Migrating from vim", doesn't nearly cover all the differences between vim and helix. If there wasn't a keybinding file I could use, I would need a document that covers as many differences as possible between vim and helix. I found this document when trying to figure out a mapping in helix, and it didn't cover it. I can't remember what the mapping was though.
I really want to use helix - I want lsp and tree-sitter out of the box in the terminal. I hate managing a neovim config. But I also use tons of other machines, and vim is on all of them - I can't afford to unlearn that muscle-memory. I think you can make helix both it's own editor with it's own take on things, and capable of adapting to people who are heavily invested in the vim paradigm.
We can't invert the bindings though (wd -> dw) because that would require a big internal change to add operator pending mode:
When you press `d` in vim, that enters the operator pending mode, where it will wait for an object to be specified, in this case `w` and then delete it.
In a selection first model, `d` is very simple: it just always deletes the selection. So you select a word, then delete.
It has the potential to be much better at editing code (with a "sense" of the ast) than vi. The trade-off might be that it's slightly more difficult to edit arbitrary/semi-structured text.
I believe (but it's a little early to be sure) that the difference in approach to editing is a net win when working with code.
My advice if coming from vi(m) is to treat helix as a new editing experience - like you would if you were trying out emacs or acme.
The nuanced similarities then to overshadow how helix is different from vim - for better and for worse.