[archseer]

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 :)

[jarbus]

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

[archseer]

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.

[e12e]

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.