Are we Helix yet?

[luccahuguet]

The definitive meta-discussion to make Helix mode on Zed truly great

Zed contains a nascent community-supported Helix implementation. While the basics should work, there are many features missing, and a significant number of smaller differences between how things work in Helix vs Zed. Zed's team would love to have your help working on these!

The point here is to join forces and capture the users input in the best way possible, listing what already works and what doesn't and bugs we find, so do comment anything you find that is not here yet

Notes

• The idea of a helix mode in Zed is loved by many! See here: Helix keymap #4642
• There is even a total of 300$ in bounties, to be claimed, for advancement on this: https://app.opire.dev/issues/01J6HJZCK02FVD4XG900FY36EE
• You can read the official Zed documentation on helix-mode here
• This is an ongoing process, and helix mode on zed will never be exactly 100% equal to helix. The state of helix's mode will depend on contributions, how important a certain feature is, and zed team's take on how far we want to be before we can answer the question "are we helix yet?" with "yes, we have achieved helix"
• If a behavior is currently different from what is expected from a helix-mode, and you did not find an existing issue (open or not) regarding this, please open an issue with "Bug Report (Other)". Keep in mind some helix features might be vetted by the Zed if they are deemed unwanted for some reason (too specific, performance issues, bad UX, etc)
• As of Octorber 30th, 2025, the Zed team has been extremely helpful and cooperative as the helix-mode gets better and better. The State of the Helix experience has advanced a lot, and feels really good and intuitive to use, as noted by many users.

Some of the open issues/missing features

You should be able to find more open issues by searching with the helix label like this or by making a generic search of the term helix like this

• Amp mode with gw:
  • Ref 1: https://helix-editor.com/news/release-24-03-highlights/
  • Ref 2: easymotion vim #4930
• Which-Key like menu #10910
• helix mode: v2w selects one character too many #31997
• Helix mode, problems near empty line at the end of the file #35616
• Zed does not respect "ensure_final_newline_on_save" with Helix mode #37793
• Helix mode: sometimes v excludes current character from selection #38121
• helix match mode is incomplete #38151
• In helix mode, on zed, Ctrl-s saves the file instead of saving selection to a jumplist as it should #41580
• Line misindentified in Helix select mode when ␤newline is selected #41743
• In Helix mode subword movements do not select the last subword unlike word #41767

Some PRs that already got merged (contributors can use them as inspiration)

• Allow specifying no base keymap #9471
• Implement Helix Support (WIP) #19175
• vim: Add delete action to HelixNormal mode #21544
• Flesh out helix bindings #28103
• vim: Fix escape key switching back to default mode instead of normal mode #31843
• Add alt-s to helix mode #33918
• helix: Fix replace in helix mode #34789
• Helix Select Mode #37748
• Initial support for helix-mode paste #37963
• helix: Change selection cloning #38090
• helix: Apply modification (e.g. switch case) on a single character only in helix mode #38119
• Add a helix-specific substitute method #38735
• Implement regex_select action for Helix #38736
• Re-order Helix keymaps and add alt-o/i/p/n #40527

Table of commands still to be implemented

by @romaninsh

Toggle

Mode	Related Keybinds	Description	Implementation Plan	Difficulty	Related Issues/PRs
Movement	alt-.	Repeat last motion (different from last change)	Add implementation for remembering and repeating last motion	medium	--
Movement	ctrl-i, ctrl-o, ctrl-s	Jump list navigation	Implement a jump-list system	medium
Changes	--	Paste while preserving selection	Implement helix_paste action that maintains selection after paste	medium	--
Changes	alt-u, alt-U	Move through history/undo tree	Implement history navigation commands	medium	--
Changes	space y, y	Clipboard handling (explicit vs implicit)	Improve clipboard handling based on system settings	easy	--
Shell	|, alt-|, !, alt-!	Pipe selections through shell command	Implement UI for shell command input and multi-selection piping	hard	#12598
Selection	s, S	Regex selection (select/split)	Implement UI prompt for regex input, then modify selections	medium	#31561
Selection	alt-s	Split selection on newlines	Re-implement to better mimic helix behavior	easy	#31562
Selection	--	Merge selections	Implement selection merging functionality	medium	--
Selection	alt-(, alt-), (, )	Primary selection rotation	Implement primary selection concept and rotation	hard	--
Selection	--	LSP-based selection actions	Implement LSP-aware selection manipulation	hard	--
Search	*, Alt-*	Search for current selection	Add keybinds to search for selection and navigate with n	easy	--
Goto	--	Labels/jump targets	Implement label-based navigation (reuse vim functionality)	medium	--
Match	m i, m a	Object handling (inside/around)	Complete implementation and add more test cases	medium
Match	--	Multiple cursor test cases	Add comprehensive tests for multiple cursors with existing selections	easy
Match	m s, m r, m d	Surround replace/delete operations	Implement surround manipulation with special attention to edge cases	medium	#38151
View	z, Z	Sticky view mode	Implement new helix_stickyview mode	hard	--
View	--	Non-sticky view commands	Add keybinds for view commands in normal/select modes	keybind	--
Window	Ctrl-w	Window management	Minor alterations to existing vim window mode	easy	--
Space	space + keys	Space mode commands	Populate keybinds and alter to match Zed panels	keybind	--

Current state of things and guidance on how to implement the missing features

by @romaninsh

Toggle

Helix basic support and structure

Status: General logic is well-developed and Helix mode is quite usable. It no longer drops into vim mode and no longer relies on hacks for select mode or word movement.

Implementation lives under vim/helix/ and could use a small re-org to avoid PR conflicts and oversized files. I’m happy to overhaul the Helix structure.

Initial implementations of ranges, objects, and operators are in. This enabled the [ / ] motions and can be extended to cover m mode (needs a bit more work).

Helix movements are more complex than vim—many imply selection changes in both directions. Complex cases (like Alt-arrow movements) now work and support multiple cursors.

Repeat modifiers are working relatively well. Overall, the foundation is almost there.

Movement

Missing pieces

• We lack Alt-. (repeat last motion). This differs from “last change,” so there’s no simple reuse. We need to remember the last motion to repeat it.
• jump list (Ctrl-I, Ctrl-O, Ctrl-S) needs a proper jump-list implementation.

Everything else is implemented or straightforward to add.

Changes

• paste while preserving selection — currently paste resets/replaces selections. Needs a helix_paste implementation.
• Move through history (Alt-u, Alt-U).
• space y vs y — Helix only uses the clipboard when explicitly requested; may need refinement depending on system clipboard settings.

Everything else is implemented or easy to implement.

Shell

Requires some UI changes. vim uses '<,'>! as the command prefix, but in Helix that’s not relevant because multiple selections can be piped directly to a command. Needs a full implementation here.

Selection manipulation

• s, S — prompt for a regex via UI, then modify selections (needs proper implementation).
• Alt-s — currently generic; likely re-implement to better mimic Helix.
• merge selections — no existing helper; needs to be implemented.
• primary selection — Helix can rotate through selections; Zed treats selections equally. This needs design thought.
• LSP actions — Helix’s built-in LSP powers many selection ops; vim motions don’t. Will require extra work.

Overall: selection manipulation needs substantial work.

Search

• * and Alt-* should search for the current selection with subsequent n to step through. Should be easy to implement.

Goto mode

• labels — worth a focused look; there may be vim functionality we can reuse.

Other motions should be easy to add.

Match mode

• object handling — partial, needs more testing.
• Add test cases, especially with multiple cursors and existing selections.
• surround replace/delete needs particular attention.

View mode

Propose a new helix_stickyview mode for sticky behavior. Non-sticky likely doable with keybinds in normal/select modes.

Window mode

Ctrl-W exists from vim; may need minor alterations.

Space mode

Can be populated via keybinds and adapted to match Zed panels better.

[dgmulf]

As a veteran Kakoune user (and source code contributer), I would encourage anyone interested in the selection-first modal editing style to study Kakoune itself. Helix still has not caught up to everything that made Kakoune such a beautifully designed and influential piece of software; as such, helix_mode is now an imperfect copy of an imperfect copy.

[Malix-Labs]

helix feels like a mishmash of kakoune and vim which makes makes normal and visual mode have a lot of overlap and redundancy

Helix has insert, normal, and select mode (Select is akin to Vim's Visual)

But it also is motion-first like Kakoune

Saying Helix normal and visual mode are overlapping and redundant is like saying Vim's hjkl is redundant to MnK's arrows

They have different workflows

if enough people are used to helix bindings there's value in support it

Also maybe there is value in supporting it if they are objectively good and interesting?

Having used Vim, Kakoune, Helix, and Emacs motion each for an extended amount of time, I personally strongly prefer Helix's motions overall, for example

vim is not perfect either and has a lot of quirks yet it certainly objectively the most important to have due to it's familiarity.

To be clear, there was never a debate about removing Vim motions support in Zed

[eugenesvk]

This video covers it really well, helix

That's a bad video.

Didn't get the first complaint, you could also bind Shift+W in helix mode to do the same thing as in kakoune?

And the command length character count is also strange, $ isn't one character, it's Shift hold + 4 of two keys + You have to hold one. And why would that be easier in your head isn't even explained.

Then, failing at specifics, it goes into an even more vague territory of philosophy

[adrusi]

As a longtime kakoune user, I'm also disappointed by how not-actually-kakoune Helix's bindings are.

Kakoune does the idiosyncratic thing where, since the "cursor" is always really a 1-character selection, it's always on a character rather than between characters. When you Get it and grow accustomed, it's very powerful because it pares down the editing ontology and makes things fit together nicely. But it also gives it a steeper learning curve and makes the prospect of integrating it into an existing editor potentially more challenging.

I dont think there's anything wrong with there being a helix mode. But I'm certainly disappointed that it's not what i thought it would be. The hope of a eventually supporting a kakoune-like editing experience was what pushed me over the line to trying out zed.

Would be good to get an idea from the maintainers of whether patches that implement a distinct kakoune mode would be welcome.

[Malix-Labs]

@adrusi I encourage you to create / upvote an existing feature request about a kakoune mode specifically

[NewtonChutney]

Didn't get the first complaint, you could also bind Shift+W in helix mode to do the same thing as in kakoune?

Thanks for that.. Many people do indeed use helix with some kakoune binds..
I've switched over to kakoune style binds for extending selections in normal mode in helix.. Have to do the same in zed now.. I've remapped the default helix bind of W to A-w
helix conf:

[keys.normal]
"W" = "extend_next_word_start"
"A-w" = "move_next_long_word_start"
"A-W" = "extend_next_long_word_start"
"B" = "extend_prev_word_start"
"A-b" = "move_prev_long_word_start"
"A-B" = "extend_prev_long_word_start"

zed conf tbd

[dream-dasher]

Awesome, thanks for making this tracking issue.

1) Can we get some example PRs that added Helix functionality?
I'd be interested in contributing and seeing where other people have actually landed code would be quite useful.

2) Similarly, by what mechanisms does "helix_mode": true,` actually gate code: this would also be helpful in tracking.

3) One of the most useful things about Helix is discoverability -- the visual keymap popups continue the trend of intermediate highlighting -- allowing speed with optional feedback. Has there been any discussion on mechanisms for this? I realize it's probably early, but worth bringing up now as that's a large part of what makes Helix so usable, I think it's fair to say.

[mahalel]

I tried to put up a list of PRs which got merged, from the original issue:

• vim: Fix escape key switching back to default mode instead of normal mode #31843
• Implement Helix Support (WIP) #19175
• vim: Add delete action to HelixNormal mode #21544
• Flesh out helix bindings #28103
• Allow specifying no base keymap #9471

[luccahuguet]

Added to the discussion post (a couple days ago) after reading your comment, thanks

[eugenesvk]

For 3. see which key proposal PR #34798

[eliaperantoni]

I filed one more issue #33838 that has to do with visual mode. I also added an extra 100$ to the bounty so it's 300$ now 😊

[luccahuguet]

Awesome! I updated the discussion

[eliaperantoni]

I think a good next step to bridge the gap with Helix would be introducing a new mode: Select (or Helix Visual or Helix Select).

Then we could add some simple features to it to prove that it's worth existing separately from Vim's Visual like:

• In helix_normal mode, alt-s doesn't split selection on newlines #31562
• In helix_mode, visual mode, alt-; does not invert the anchor of the selection #33838

And then later, someone could implement #31561 which seems a bit trickier.

@ConradIrwin would you be open to a new mode that works like this? :)

[Malix-Labs]

I agree about separating Helix's Select from Vim's Visual

Not splitting them could potentially cause issues down the road

[ConradIrwin]

👍 Yup, adding select mode seems sensible to me.

[eliaperantoni]

@ConradIrwin I submitted a PR #34136 🥰

[Dreaming-Codes]

I'm encountering a strange behavior: when I delete a character with d in Helix normal mode, it switches to Vim normal mode. Has this already been reported?

[tibitTW]

Seems matching mode also aren't implemented yet ?

[luccahuguet]

It's in the main post, you might've skipped past it

[tibitTW]

Yeah I skip that indeed

[haxfn]

Why are keybindings just protocols: Why aren't they actually implementations with interfaces. Each new time someone thinks of using a keybinding paradigm in their app, they have to half cook the implementations. Instead the interface should be there to plug, only part left to him should be to wire the interfaces to parts of their app.

[jabcross]

This is just a thought, but one of my favorite features of Helix is the command palette that shows up and shows your options when you're using a sequential keybind:

If you press space:

If you press g:

Dunno how far-fetched it would be to get something like this working in Zed.

[serban]

There is an existing feature request for this: #10910. Give it a thumbs up! 👍☺️

[jabcross]

Neat. Maybe it would make sense to add it to the list of related issues?

[luccahuguet]

neat!! added it

[sa1]

Is a hybrid mode possible? Emacs keymap in the insert mode, and helix otherwise?

[jabcross]

You could certainly remap the keybindings to do that.

[sa1]

Yeah, but tough to figure out the correct context for every keybinding. If someone has an example, that would be great!

[akdor1154]

Classic Hat Guy...

[praguevara]

I've opened #34765 to better match helix's insert and append.

[praguevara]

I feel like yanking with the cursor on top of a single character should only yank that character, and not the whole line. A workaround is to enter visual mode before yanking.

[praguevara]

[fnuttens]

Yes it does, changing text in helix effectively yanks it to " register. Your system clipboard remains unchanged, though.

[praguevara]

You're right. I will delete this then

[mati865]

FYI to replace with clipboard content use R

[Nico-Mayer]

I've encountered an issue with vim::SelectNext command in Helix mode. When I try to select the next occurrence of a word, it unexpectedly includes the two following appearances instead of just the immediate next one. Can anyone explain why this behavior occurs?

  {
    "context": "Editor && vim_mode == helix_normal && !VimWaiting && !menu",
    "bindings": {
      "space n": "vim::SelectNext",
    }
  },

Bildschirmaufnahme.2025-07-29.um.14.46.30.mov

[romaninsh]

I'm new to zed but with some help from @fantacell, I've added a number of smaller incremental improvements:

• helix: Allow yank without a selection #35612
• helix: Improve "x" behavior #35611
• Refactor Helix selecting movements (w, b, e, W, t, T) #35501
• Add "shift-r" and "g ." support for helix mode #35468

Then we have #35687 and #34060, great to see helix development picking up some steam!

[ConradIrwin]

Thanks for all these! They are on my list to get to, but I'm traveling this and last week so a bit short on time; I hope to have some feedback to you late next week

[dryBoneMarrow]

Double pressing v (entering visual mode and exiting it) returns to vim's normal mode instead of the helix normal mode

[fantacell]

#34136 fixes that

[i1Fury]

This issue is plaguing my programming experience as well .-.

[romaninsh]

Should be resolved by #37748 and #38117.

[luccahuguet]

I think a good idea

Is to go for "helix tutor" parity

Or at least use it as a baseline

Example: "for now the goal is to support everything from helix tutor except this and that"

[luccahuguet]

Breaking Change

Helix users should remove "default_mode": "helix_normal" from their settings. This is now the default when "helix_mode": true.

• Source: helix: Streamline mode naming in the UI and in settings #38870

[luccahuguet]

this can be useful to us: #39261

Added support for action sequences in keymaps. Example:
["action::Sequence", [ ["editor::SelectLargerSyntaxNode", "editor::Copy", "editor::UndoSelection"]

Also, on a personal note, I've been using Zed with helix mode and it's really nice.
And Im the author of Yazelix, which is like a terminal IDE (yazi + zellij + helix), so I'm picky about how I edit my code and manage terminals...

[luccahuguet]

Nice. Why did you opt for a discussion instead of issue?

It's a bug imo.

I think it makes more sense as an issue. I could be wrong though.

[eugenesvk]

Becuase I'm not sure to what extent Zed targets Helix compatibility, so not sure whether a deviation like this is expected and a "compatibility feature request" due to the fact that full compatibility was never promised (and which are redirected to discussions), or a bug

[luccahuguet]

Becuase I'm not sure to what extent Zed targets Helix compatibility, so not sure whether a deviation like this is expected and a "compatibility feature request" due to the fact that full compatibility was never promised (and which are redirected to discussions), or a bug

I understand

I think the most efficient way to act is to consider everything that is different from helix, and not explicitly mentioned by the zed team as a non-goal, as an issue

This might be easier for maintainers too

They can then easlily close the issue as not planned

Or say "hey we're not sure about this, lets move this to a discussion for a bit, and reach a final conclusion after some debate"

I only fear that opening it as a discussion will make it get forgotten

That's my two cents. And as I said before, I could be wrong.

[eugenesvk]

Ok, changed to an issue and updated the link above

[luccahuguet]

Ok, changed to an issue and updated the link above

Nice, let's see how it goes and stay tuned to feedback from the zed team too

Should they mention a feature Zed does not want helix-mode to have, but helix itself has

Then I'll update the post with this information

[HairlessVillager]

Still missing:

1. g w
2. m s (

Add these features 🚀 🚀 🚀 and I'll use Zed day and night ❤️

[NewtonChutney]

Yeah.. I miss match surround add, and replace (every once a while 🤫)

[malj]

Agreed, g w (goto_word) is essential in any Helix mode, it makes navigating text faster than any other editor

[kraftwer1]

#5289 (comment)

[atahrijouti]

Is there any reason alt-o and alt-i aren't added? or should I go ahead and add them?

Edit: Created #40527 to add alt-i, alt-o, alt-p, alt-n

[ConradIrwin]

PRs welcome!

For the default Mac keyboard, alt-X key-bindings are not allowed, but happy to have things in the helix map

[atahrijouti]

@ConradIrwin #40527
Added them here. I also went ahead and re-ordred the helix_mode & helix_select to look more like the documentation of helix in terms of how the keymaps are ordered.
I believe that this way further contribution would be much easier.

[luccahuguet]

thank you @atahrijouti #40527

[Nico-Mayer]

Currently, there is an action to toggle Vim mode, but no equivalent to toggle Helix mode. I think this would be a nice addition.

[eugenesvk]

One issue with the lack of primary selection: if you select current+3 words down with ["editor::SelectNext" ,{"replace_newest":false}] and want to undo the last 2 words via ["editor::SelectPrevious",{"replace_newest":true }], you'll instead select current-2 extra words since "previous" is relative to all selected ranges, not the primary selection

[eugenesvk]

Implement new helix_stickyview mode

Could there be an easier workaround - allowing commands to set vim_operator mode that you could then match in your keybinds via vim_operator == my_custom_operator?
Then you could have a chain command that does its function and in the end sets operator to my_custom_operator and then you could duplicate keybinds (without the my_custom_operator chain ending) with this custom operator condition? And those would be repeatable commands untill you cancel the operator with Esc or some other keybind

Yes, this seems like a viable option. Even currently you can have this workaround: you can have a sticky mode, but only for a short period of key sequence wait time

This creates a sticky "View mode" mapped to v with the following j/k scrolling down/up repeatedly until you press nothing for 0.X timeout

 "v j":["action::Sequence",["editor::LineDown",["workspace::SendKeystrokes","v"]]],
 "v k":["action::Sequence",["editor::LineUp"  ,["workspace::SendKeystrokes","v"]]],

Althout this one doesn't work in Insert mode with alpha keys since the typed key is not removed like for a regular sequence
But then you have a furher hack of mapping the continuation mod to non-alpha key at the cost of having to duplicate commands

This cleans up the typed v in insert mode (and alt-v could be some alt-shift-ctrl-f14 combo that you'll press normally since you don't even have a F14 key...)

 "v j":["action::Sequence",["editor::LineDown",["workspace::SendKeystrokes","alt-v"]]],
 "v k":["action::Sequence",["editor::LineUp"  ,["workspace::SendKeystrokes","alt-v"]]],

 "alt-v j":["action::Sequence",["editor::LineDown",["workspace::SendKeystrokes","alt-v"]]],
 "alt-v k":["action::Sequence",["editor::LineUp"  ,["workspace::SendKeystrokes","alt-v"]]],

If only you could manually configure the wait time for each of the groups and add which-key visual mode (after another configurable wait time) it'd be even a better version of Helix sticky modes! And you can only make some of the "menu" commands sticky rather than having the whole menu sticky.

(the custom operator approach would still be better as it'd help avoid command duplication)

Copied the explanation to a separate thread since its usefulness isn't limited to Helix mode #41759

[eugenesvk]

Another idea on how to make creating all the various modes easier - is to make the base commands more powerful and accept arguments so that, ultimately, a mode would be a simple collection of keybinds that you can either activate as a "layer" (via a mechanism that doesn't exist but similar to the one suggested #6447 (comment)) or use piecemeal in any "mode", for example, to run a helix move-by-word command (that selects the latest word) vs a vim move-by-word command (that doesn't select anything) you'd simply pass select=true no_extend=true to the former

#41083

[eugenesvk]

upd: fixed in nightly
One more inconsistency to add to the list with jumping around search matches: nothing is actually selected unlike in Helix which always selects #41164

[luccahuguet]

Thank you for your contributions

[luccahuguet]

Created an issue regarding ctrl-s and expected saving position to jump list behaviour:
#41580

[luccahuguet]

@romaninsh Some of the things in your comprehensive analysis are no longer accurate, as the pace of implementations remains strong, and more features got implemented, thankfully 🙏🏼

Would you (or someone) like to do a revaluation on the current status, so I can update it in the main post?

[eugenesvk]

Helix' goto_first_change/goto_last_change commands are missing, same for diagnostic goto_first_diag/goto_last_diag. See a more general feature request here #41665 (there are a few non-helix commands with the same missing first/last pair)

[eugenesvk]

Line misindentified in Helix select mode when ␤newline is selected, so moving to line beg/end differs in select mode vs normal mode #41743

[eugenesvk]

Another issue for your mighty list: subword movements do not select in Helix mode

[luccahuguet]

@eugenesvk is on fire 🔥

Our mighty list is up to date now