8 ms·

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

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-Vim https://github.com/helix-editor/helix/wiki/Migrating-from-Vi... - Our Matrix chat is always happy to help with questions :)

jarbus 4y ago
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 https://github.com/Extrawurst/gitui
- archseer 4y ago
  There's this config you might like: https://github.com/LGUG2Z/helix-vim 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.
  - e12e 4y ago
    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.

jarbus 4y ago

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 https://github.com/Extrawurst/gitui

archseer 4y ago
There's this config you might like: https://github.com/LGUG2Z/helix-vim 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.
- e12e 4y ago
  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.