Helix 22.12(helix-editor.com)
helix-editor.com
Helix 22.12
https://helix-editor.com/news/release-22-12-highlights/
11 comments
1) there's a pull request that fixes this but needs a bit of polish (https://github.com/helix-editor/helix/pull/1819)
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)
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)
Hey, thanks for creating helix. IMO it is a big improvement to neovim and it is so much easier to get started with it. I was really sceptical at first, but its now my main editor.
FYI your github link in your opencollective [0] profile seems to be wrong?
[0] https://opencollective.com/blaz-hrastnik
FYI your github link in your opencollective [0] profile seems to be wrong?
[0] https://opencollective.com/blaz-hrastnik
Thanks for the kind words! Fixed the link :)
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.
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…
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...
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...
> 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.
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/...
Fair enough, but IMO one of the selling points of Helix is sensible defaults (kind of what Neovim was to Vim), so I'm quite torn on on that: modifying (Neo)Vim config all the time doesn't really make me happy anymore.
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.
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 personally main Emacs, so Helix really only scratches the itch of quick config file edits via terminal for me. However, I also don’t use VSCode, so I can see how that adds an additional wrinkle to things.
thanks for sharing your key remapping. most of it is very sane, i copied it.
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 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.
A contributor of Helix is working on the implementation of a file tree view [1].
However, the contributor seems busy at the moment.
[1] https://github.com/helix-editor/helix/issues/200
[1] https://github.com/helix-editor/helix/issues/200
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.
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:
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"?
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"?
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.
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.
Auto-saving is off by default
Iirc, you can turn this behavior off with `editor.auto-save = false`.
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'.
If you use my Helix keybindings[1], you only have to remember “Vd”.
[1] https://github.com/danieljaouen/dotfiles/blob/master/topics/...
[1] https://github.com/danieljaouen/dotfiles/blob/master/topics/...
Agreed. A helix-mode extension for VSC would be ideal.
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.
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:
- `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 :)
> 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 :)
Ah, I'm noticing that my parent comment didn't quite say what I intended!
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.
[0] https://github.com/Extrawurst/gitui
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.
[0] https://github.com/Extrawurst/gitui
There's this config you might like: https://github.com/LGUG2Z/helix-vim
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.
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.
I tried the "vim" keybindings, but I quickly gave up on it. Helix is a modal editor, but it is not (imnho) a vi/vim-like editor.
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.
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.
needs more newlines still, blocker for me
https://github.com/helix-editor/helix/issues/4274
Shouldn't the file type formater handle that?
Cargo is pulling a metric fork-ton (300+) of dependencies - is that normal?
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.