Author here. I listen to feedback, but it's hard to incorporate every possible requested feature without the codebase becoming an unmaintainable mess.
We're a small team with limited time and I've always emphasized that helix is just one version of a tool and it's perfectly fine if there's a better alternative for some users. Someone with a fully customized neovim setup is probably going to have a better time just using their existing setup rather than getting helix to work the same way.
Code editors in particular are very subjective and helix started as a project to solve my workflow. But users don't always respond well to having feature requests rejected because they don't align with our goals. Plugins should eventually help fit those needs.
I like this response. Kudos to sticking to your vision; it's easy to be swayed by users into building a kitchen-sink-fridge-toilet. If you build for everyone, you build for no one.
What if I need to cut and paste things from one file to another? Registers wouldn't sync I'm guessing, so I'd have to do something hacky with the system clipboard
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.
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:
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.
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.
