Vim keymap for Helix

[florinungur]

Heyo!

Would love if on the Key Remapping page we'd be able to download a config.toml file that has the complete Vim keymap.

This is the only point of friction that is stopping me from using Helix. I don’t care which keymap is better, I care that Vim’s is older and more widespread -- there’s a Vim keymap for every IDE.

I can't find a roadmap for Helix, do you plan on adding other keymaps as a first-class citizen?

[the-mikedavis]

Vim uses a different editing paragidm (verb-object) than Helix (select-then-act). We are not interested in supporting multiple paradigms (see the vision doc).

[the-mikedavis]

That being said, there is a community project for vim-like bindings: https://github.com/LGUG2Z/helix-vim

Although I would encourage you to not use that and try to learn Helix first. After all, if Helix were just Vim written in Rust, what would be the point?

[geometryolife]

Although Vi’s key mapping is very common and versatile, since Helix is chosen, you can feel its unique charm by directly using native keys. @florinungur

[certik]

I tried helix-vim, and while it gets closer to Vim, it does not get close enough, at least for me.

[certik]

After all, if Helix were just Vim written in Rust, what would be the point?

The point would be all the points you have at your page: https://helix-editor.com/, that is, "Multiple selections", "Tree-sitter integration", "Powerful code manipulation", "Language server support", "Built in Rust, for the terminal" and "Modern builtin features". All these I think could be supported with Vim keybindings as well.

[0atman]

I agree with you that select-then-act is better than verb-object. That's OBVIOUSLY the right way round.
But I value uniformity in my tooling more than special cases that are better suited to their domains.

KEEP HELIX'S select-then-act defaults. But allow us to configure native bindings for emacs and vim modes.

I'd like to urge the decision makers here to re-think this. Consider vim/emacs bindings a gateway drug to your editor. Reducing the barrier to adoption. This will allow 1000x more users to use Helix

As an open source project, users are everything.

I could not in good faith recommend Helix in my recent round-up of Rust tooling (https://www.youtube.com/watch?v=dFkGNe4oaKk) precisely because of this issue.

---

A case study:

Colemak and Dvorak are much faster and ergonomic than qwerty to type with. I don't use them (despite using colemak for a few years) because the rest of my tools use qwerty.
Standardisation beats technical correctness every day of the week.

---

What have you got to lose here?

1. If you don't yield on this point, you risk helix being relegated to obscurity.
2. If you do make this concession, then yes, most of your users will use the inefficient vim or emacs modes you provide. BUT YOU WILL HAVE 1000x MORE USERS because they can now use Helix!

How many of them will, after making helix their default editor, try the helix select-then-act mode and love it and switch? Far more than you would by restricting helix's userbase by not supporting an on-ramp through supporting other input methods natively.

Let me say that clearly: You are REDUCING uptake of your new better mode with this decision.

---

Second case study, DIRECTLY RELATED to your domain:
evil mode got me into the emacs because they ported all of vi into emacs. The explosion of interest in emacs thanks to Spacemacs and Doom is because of Vi mode.

The vi/emacs editor wars are over because emacs has all of vi in it. You can have both.

Don't start another one, learn from the past.

---

The moment you include industry-standard keybindings (I'd take just vim, but urge you to also include an emcas-y (or nano-y) mode) I will be able to recommend Helix.

You are fighting an impossible battle against the inertia of an entire industry.

[filipdutescu]

While I definitely applaud your passion and drive and in no mean intend to come off in a wrong way, one of Helix's tenants is not being made for mass adoption. It does not aim to accommodate everyone, nor dethrone Vim/Emacs etc.

We also got in this proverbial mess precisely due to software trying to implement the same mode of operation as Vim/Emacs, which, as you said yourself, is less than ideal. Hence, I would rather force a better way onto users than keep using the existing "worse" manner of usage. Users who would migrate and use the Vim mode would most likely keep on yhe Vim mode.

This could also introduce a tone of bugs exclusive to this mode, which would only hinder progress on Helix. Already maintainers struggle to keep up with the huge amount of work put in. With a new mode that would increase pressure on them pointlessly, in my opinion. It would also mean sidetrack almost everything else for a big refactor, instead of adding QoL improvements such as the Debugging overhaul.

Hope this puts a bit more context into why maintainers might be reluctant to implement such a feature. Please keep in mind I am just a contributor, not a maintainer, so I might not be right in all aspects. Just throwing my 2 cents here.

[certik]

@filipdutescu I am happy that Helix is pushing a new fresh way of operation. I have developed and maintained many open source projects and know exactly how it feels from the maintainers perspective.

From my "user" perspective, I only use probably 20 Vim commands, just like I only use about 10 git commands (out of the hundreds). I've used Vim for over 20 years now, and I first switched from Vi to Vim precisely because the defaults were better, then I switched to Neovim because some of the defaults are even better, and I would switch an editor to Helix or a similar alternative if the defaults were even better. So I think there is a great opportunity for somebody to do this. Helix maintainers said they don't want to go this path for understandable reasons and their choice should be respected. But somebody else reading this will hopefully do this, whether in Helix or a new editor. I think they will have a lot of users, myself included.

[archseer]

@0atman

I could not in good faith recommend Helix in my recent round-up of Rust tooling (https://www.youtube.com/watch?v=dFkGNe4oaKk) precisely because of this issue.

I find this amusing because you could have at least mentioned it and explained your gripes with the keymap, allowing your viewers to draw their own conclusions, but okay, I respect your decision.

The whole idea behind helix is that it's OK to break things and be different! Sticking to "standards" and being afraid to experiment is how things ossify and suddenly we're stuck. Could you imagine if the creator of vi got this exact feedback and we'd never have gotten vi(m) keybindings in the first place?

If you already have an existing setup that works and you aren't prepared to re-train muscle memory then it's probably better to stick with the existing setup ("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."). Users that are looking for "Vim, but in Helix" would probably benefit more from configuring a couple of plugins to get the behaviour they want in Vim rather than trying to shoehorn a different mode into Helix. I never had any success with evil mode or Spacemacs precisely because it worked like Vim but it didn't work exactly like Vim. I quickly realized I wasn't actually treating it like Emacs, I just wanted a better Vim.

Colemak and Dvorak are much faster and ergonomic than qwerty to type with. I don't use them (despite using colemak for a few years) because the rest of my tools use qwerty.

But I do! I spent the effort to learn the Norman layout (and I can still type QWERTY... that muscle memory isn't suddenly lost) and I think choices are a wonderful thing. An alternative layout doesn't have to be the default but it's there for a niche userbase that prefers it.

Now for the technical side: I've answered this before in more detail in another issue; but the way helix models internal state is fundamentally different to the point where we'd have to rewrite most commands from scratch just to support Vim-like keybindings. In Vim, because the order is inverted when you press d the editor needs to enter a special "operator pending" mode and await for more inputs that specify the "textobject" you're operating on. Whereas in Helix we just simply... operate on a selection. I've got no interest in spending significant amounts of time to do that just to add Vim emulation (that would probably end up being just different enough to annoy you because it's not actual vim! Most "vim modes" have this problem)

Let me say that clearly: You are REDUCING uptake of your new better mode with this decision.

https://twitter.com/jntrnr/status/1622654114831417344

It hasn't hurt our adoption so far. If anything I'm absolutely astonished and humbled by how many passionate users we've gotten since the initial release. Vim/modal editing is already niche enough (let's face it, the majority uses VSCode or similar IDEs) so I expected that a niche take on a niche won't attract more than a handful of users.

A different keymap is a hurdle, but apart from selection-first the keys aren't really that different and only take a couple of days to adjust to. We also get an influx of VSCode users that have never managed to switch to Vim, but found Helix a lot more intuitive and ended up sticking with it.

[LadySerena]

Posting this here since this was originally a reply on mastodon and not in the issue proper

I've found helix's non vim and emacs bindings really helpful for me to adopt this editor. I've tried vanilla vim, neovim, vanilla emacs, and spacemacs both evil and holy modes. I couldn't really memorize the mnemonics super well and I ended up going back to the jetbrains family of IDEs.

I try out helix one day because of wanting to try out another terminal based text editor and it was an amazing experience because this was a new take on keybindings. I'm actually considering not renewing my jetbrains licenses next year because helix has become my daily driver. I think the big killer feature for me has been the selection manipulation. It handily makes up for some lsp's not being able to do certain refactors.

I guess my one request if helix does adopt vim or emacs style bindings to keep an option for the current one becuase it's really changed my workflows for the better.

Full disclosure I haven't had to unlearn years of vim and emacs bindings

[0atman]

@archseer "Could you imagine if the creator of vi got this exact feedback and we'd never have gotten vi(m) keybindings in the first place?"

@LadySerena "I guess my one request if helix does adopt vim or emacs style bindings to keep an option for the current one becuase it's really changed my workflows for the better."

I fear I am misunderstood. I don't want helix's superior kebindings to be removed in favor of vim and/or emacs. I want all three.

[0atman]

Helix is an INCREDIBLE PROJECT, the maintainers and collaberators have done an BRILLIANT job, and I thank you and them.

But it's more than a prototype of a better way of editing, look at the way you present your features:

You don't mention this new way of editing ANYWHERE on the front page. Why is that? I don't think it's as important as you think it is.

A pure Rust editor that has all the above features would be INCREDIBLE. If only we could use it.

[certik]

I don't know how technically feasible is to maintain all 3 modes (Helix, Vim, Emacs). I do use the Vim plugin for VSCode, and that works reasonably well. The helix-vim I think would require some changes in Helix (new commands) in order to emulate Vim well enough.

[0atman]

I'm trying out the bindings over in the above-linked helix-vim and it's working great so far, perhaps I can have my cake and eat it, even if it's not built-in 😁

[archseer]

this new way of editing

It's mentioned right there under the first bullet point. I've checked Kakoune's website and they also focus on multiple selections rather than saying "a novel modal editing experience different from vim!"

If only we could use it.

You can use it by doing what every other user did and using hx --tutor to learn how to use it. You get a new laundry machine, you read the manual rather than demanding microwave controls on it. That is after all, how we learn a new tool.

Imagine getting into an airplane and trying to convince the aeronautical engineer to try to instead build a plane that has a steering wheel and accelerator and brake pedal to help all the people who are used to cars transition to airplanes.

[hectorgrey]

So, I certainly can use helix, and if I didn't also rely on vim when editing over ssh on a semi-regular basis, I'd be happy to make the transition fully. The issue is having to use both, because they're both similar enough to make helix really easy to learn the basics for, but different enough that the differences are irksome when you have to switch back and forth. It's an excellent editor that I just have trouble getting used to because I'm also using vim. Still, it might be worth a look at helix-vim to see if that solves my issues.

[certik]

For those trying helix-vim, I made some improvements here: https://github.com/certik/dotfiles/blob/182ce03774b31347e6430ab9f661cfa12b22e76b/.config/helix/config.toml, but it still behaves differently and I think to bring it closer, one would need to add new commands to Helix. One issue is highlighting with V, it doesn't highlight the full line, but only up to the cursor. When highlighting with v, it does not highlight the letter under the cursor, but it counts. When pasting on an empty line, it pastes it under that line. And so on. I think to fix all these many little issues, one can create a dedicated command in Helix that does that, and then we map it. So hopefully it shouldn't break any existing default behavior.

I can use Helix and only Helix, or I can use Vim and only Vim, but I have not figured out how to use both. @archseer it's not because I don't know how to learn it, but it's really hard to switch from Helix back to Vim and vice versa.

[Renkai]

As a no-plugin vim user and Jetbrains user for more than 10 years. I recently became not so satisfied with Jetbrains so I tried a lot editor distributions includes Doomemacs, LazyVim, LunarVim and Helix. I decide to stay in Helix and for the idea of importing vim keybindings, my attitude is strong no. Why do I gave up the keymap I already familiar with? The answer is that there are severe fragmentation and ambiguity issues in the configurations/documents of other editor distributions. For example:

• Doomemacs/LazyVim/LunarVim works greatly, but I also want plugin X. The document of plugin X is only for vanilla emacs/neovim, how can I modify the example config to adapt Doomemacs/LazyVim/LunarVim?
• Doomemacs/LazyVim/LunarVim included plugin Y, but only customized part of it's keymap, I also need some other function of that plugin, how can I set those functions properly and now conflict with other plugins?
• Some plugins don't work as expected. Is it a bug of itself? Is it a conflict with the general design of Doomemacs/LazyVim/LunarVim? Is it a conflict with the other plugins in the distribution?

Think about such a situation, we have both vim keybinding and helix keybinding in helix. Many enthusiastic people created a lot of plugins, but many of them only belong to one keybinding. A new user installed Doomhelix, happy with it, then try to install a new plugin. Shoot! It doesn't work at all, what happened? It's made by a vim-keybinding maniac, he only develop plugins for the vim branch of helix, and refuse to add warnings for the helix-helix users.

Have a vim keybinding might be helpful for the existing vim users to migrate, but would be a blocker to the new users without vim experience, especially after we have a plugin system. We'd better avoid any possible divergence in the most basic things like keybinding.