5 ms·

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 c

by jarbus 4y ago

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.

archseer 4y ago
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.

by jarbus 4y ago

archseer 4y ago

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.