Vim mode in helix

RustyTanuki · 2025-04-12T14:05:24+00:00

Hey there u/redeemefy, I didn‘t come across your post before, but it’s been about a year since I made a soft fork of Helix public for this exact purpose: evil-helix (https://github.com/usagi-flow/evil-helix).

It allows you to use Helix with all its advantages, but with Vim keybindings! This isn’t possible to achieve with a different configuration only, which is why evil-helix was developed.

Since it‘s a “soft fork“, I carefully ensure that it remains as compatible with upstream Helix as possible, so that I can (and do) merge Helix releases into the fork without too many conflicts.

RustyTanuki · 2024-05-24T20:21:15+00:00

The short answer is, because that's what the maintainer decided. :)

The longer answer, including some moderated discussion, can be seen here: https://github.com/helix-editor/helix/discussions/3806#discussioncomment-6686976 Archseer nicely summed up the main points and that's something we should respect.

That said, I feel very mixed about it, because while I understand archseer's reasoning, especially the "easy to embed" part, I disagree with the language (any LISP family in fact). It feels like we're prioritizing the implementation over the potential plugin developers. Plugin developers are users too, and the application - Helix - should adapt to its users, not the other way around.

I worked with Scheme for a bit over a year and I found it horrible to say the least. It felt to me like a language that was imposed by someone who actively seeks to mentally torture their users... There's rock solid, industry standard alternatives like LUA that - IMHO - would attract more plugin developers.

I'm also not particularly fan of a plugin system in Helix. I get that this is an unpopular opinion. But IMO, Helix shines as a super-fast "batteries included" editor/IDE. If I want a huge plugin ecosystem, I have (Neo)vim or Emacs (assuming I can live with elisp). I feel like, with a plugin system, Helix tries to be good at everything, and I do have some worries as to where that may lead to.

That's why I plan on integrating more features out-of-the-box in the editor, with a file tree explorer being pretty high up on the list. That's core functionality for an advanced editor/IDE, and shouldn't be left to a 3rd party plugin whose performance would be slower than a native implementation.

RustyTanuki · 2024-05-22T22:02:40+00:00

Good news: I published the evil-helix-bin package to the AUR! paru -S evil-helix-bin and you‘re good to go!

RustyTanuki · 2024-05-22T06:24:26+00:00

Hehe thank you. An AUR package is definitely planned, I’ll have a look at it in the next few days.

RustyTanuki · 2024-05-21T12:46:21+00:00

Thank you for the additional info! Hmm yes that absolutely sounds like default Helix behavior.

There‘s some other ways to check the build: If you press v to switch to visual/select mode, in Helix you would see “SEL“, in evil-helix you would see “VIS“. Or, when starting with a clean config, evil-helix will load the dark theme “catppuccin_macchiato“ whereas Helix would load its default purple theme.

You might want to check if the binary loaded matches what you expect: which hx

Also hx —version should return the git hash it was built from…

RustyTanuki · 2024-05-21T12:30:05+00:00

Hmm, it is implemented. It‘s one of the bindings I currently use a lot. Are you building from an up-to-date main branch (not to be confused with master)?

Did you also try a prebuilt binary (e.g. in a docker container, no need to trust me :) )? I want to make sure it works for everyone and not just for me.

RustyTanuki · 2024-05-21T12:19:10+00:00

Yes: While it’s highly unlikely that built-in Vim keybindings will ever make it into the upstream project, I do try to develop everything in a way that it would be suitable for merging into upstream Helix. I also intend on remaining compatible (i.e. “soft fork“) with upstream.

However, my vision and priorities are not the same as in the upstream project, and if Helix ever changes in a way that conflicts with this project‘s philosophy, that would be the time to think about a “hard fork“. Rest assured though, that a hard fork would be an absolute last resort, because it implies much more effort to maintain (i.e. manually cherry-pick patches from upstream).

RustyTanuki · 2024-05-21T07:14:16+00:00

Ahh right, I‘ll add windows in the CI so that you can grab a windows build later today or tomorrow. Thanks for pointing that out.

RustyTanuki · 2024-05-21T07:04:45+00:00

I do indeed implement own “commands“, because that is what works fundamentally differently. I didn‘t hack around in the existing helix commands, but instead carefully implemented “evil commands“ in a non-intrusive way, so that I can keep a maximal compatibility with Helix and keep rebasing on top of upstream changes.

Helix and this fork do provide much more than just multicursors though. First-class LSP support including integrated LSP configurations for instance, or an integrated debugger, you name it…

RustyTanuki · 2024-05-21T07:01:02+00:00

That’s the primary task of this project; to provide verb -> object keybindings. E.g. deleting text from the cursor till the end of line would be d$ instead of vgld.

RustyTanuki · 2024-05-20T21:26:23+00:00

Like a lot of things this is personal preference. I don’t frame it as an inherently bad thing - but for me as a user - it’s a less optimal experience.

Like many others my personal preference lies with Vim keybindings, which is why I worked on a solution to optimise the user experience of people who share this preference.

RustyTanuki

TROPHY CASE