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

The state of helix in zed

As of Dec 19, 2025... Are we Helix yet?
Yes, we are helix!

After many issues closed, many PRs merged, and incredible work by open-source contributors and zed's own team

More info here

I am going to go ahead and mark this issue as completed since we've got plenty of helix keymap already implemented. FWIW I am also using it daily and so far it hasn't slowed me down in my day-to-day at Zed. If you feel otherwise, lemme know!

The work continues though, there is still a comprehensive list of missing features / bugs. You can see the open issues list below.

Pick one and become a contributor!

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 go with the helix mode
• 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 of the Bug type. Keep in mind some helix features might be vetted by the Zed team if they are deemed unwanted for some reason (too specific, performance issues, bad UX, etc)
• 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 can find open issues by searching with the helix label like this or by making a generic search of the term helix like this

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, on Sep 14, 2025 (much has happened since, but still useful)

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, on Sep 14, 2025 (much has happened since, but still useful)

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.

[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

[zr00da]

Support for extending selection commands (wWW et al.) would be nice to see

[dgmulf]

I’d be interested in knowing about this, but perhaps this is not the place, link it if you write it.

What is better about kakoune than helix?

For this discussion to be productive, please write the list of what Helix has not caught up from Kakoune yet

Sorry, I realize it was probably unproductive to simply flame Helix without actually backing up my claim. For me, the crucial difference is that Kakoune allows for much more precise and granular control over the selections. This is achieved through powerful selection manipulators like the mark and recall system which allows for the combination, union, or intersection of arbitrary selections, or the searching logic which allows you to spawn parallel searches starting with each cursor.

For example, what if I want to quickly format some plain text into markdown by separating the first sentence of a few paragraphs into their own separate lines and turning them into headers? In Helix the best I could do is to record a macro for getting the cursor on the next period, inserting a newline character, putting the cursor back at the start of the line, and inserting the # character, then applying that macro in several locations. In Kakoune, I can use marks to weave together all of those cursors at once without touching the mouse, then simply execute the edit once.

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

I agree. Good design is more than just a tally of what users want (or think they want) by popular vote. It's solving problems from first principles.

[infogulch]

Good design is more than just a tally of what users want

Yes but in the world of open source volunteer contributors can drastically reduce the activation energy required to get new features added by offering to develop the code themselves.

Helix mode was implemented because the users who wanted it were willing to break it down into small individual changes and put effort into each PR until it was ready to merge.

If you want a kakoune mode, then put in the work:

• Make a keymap file that gets as close as possible to kakoune with what zed offers today
• Convince some other users that kakoune mode for zed would be cool
• Identify a list of things that need to be implemented in zed needs to get closer
• Get some buy-in from the zed team to let you try
• Take the simplest thing from the list, develop it, and open a PR to practice the contribution flow
• Knock down the rest of them

This is how it worked for helix mode in zed, the majority of the code was written by volunteers that wanted to use it themselves.

[jgarte]

Why not create a new mode that acts as a superset of Helix and Kakoune, consolidating the best parts of each? 💡

Helix has some nice ideas that Kakoune lacks, and vice versa.

[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.

[xpe]

@haxfn Sounds interesting -- though I think it would sidetrack this thread. Is this written up somewhere in detail? Perhaps you could say more?

[atahrijouti]

@haxfn I think Zed and you both agree. Make a thought out interface/API, and then the user or default keymaps targets the API.

Just don't forgot the interface we're talking about here is helix's. Helix keymaps were not on Zed's radar from the get go. VIM's was.

The community wanted Helix, and Zed has allowed the community to go ahead and add helix things, while Zed team had other priorities.

So look at it from this perspective

[cornmonger]

That's the beauty of a hybrid for-profit / open-source community model; There's a direct feedback loop. No marketing surveys necessary.

[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.

[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

[jmurphy-dev]

Now that alt i,o,n,p have landed its really exposing the small subset of textobjects that are available in zed.

[ghuh]

Currently Zed supports lower case 'x' to "Select entire line or multiple lines, extending downwards" which is great!

However, Helix's recommended defaults are to also have 'X' do the same thing, but going up.

Even if Zed doesn't enable it by default, it would be nice to have an option to map 'X' to have this behavior. I don't see any Zed key map actions that would enable this.

[ghuh]

That would be fine. I'd be happy to create a custom keymap just like I did in Helix if the APi is available to make that happen. It's the lack of Zed key map actions that is really the missing feature.

[eugenesvk]

Most vim users develop their own patterns, some widely shared in the community, but the point was supporting vim not modernizing it with subjective changes based on popularity.

So why stick to the bad defaults people don't use? What is the point?

Though I guess the alternative solution could be the same as with "base" VSCode / Sublime etc keybinds - you could have an option to use "strict defaults" or a few better modified alternatives (though in this case I'd still suggest to use the improved set by default in Zed and have a strict default as an easy-to-enable option)

[ConradIrwin]

For vim mode we pull in common settings that don't break the default expectations. If X in default helix does nothing, then mapping it by default in Zed seems reasonable. If it does something that people would expect to work, then we should have it match what helix does by default.

[luccahuguet]

I think we better leave it alone then, because there is a default mapping

Key	Description	Command
X	Extend selection to line bounds (line-wise selection)	extend_to_line_bounds

Either we leave it alone, or... call a thumbs-up / thumbs down vote and see which one wins

[ghuh]

Either way, it would still be nice to have the API so it is possible to remap it manually

[atahrijouti]

Opened a PR that adds some lipstick on the helix keymaps section #43735

• Add search category to helix keymaps
• Cleanup unnecessary comments
• Indicate non helix keymap

[ghuh]

It would be nice to match Helix's g a: https://docs.helix-editor.com/keymap.html#goto-mode

In the context of Zed, I would expect it to goto the previous tab you were on within the same tab group. Essentially ctrl-tab, but just select the first entry without opening the tab picker.

The use case here is quickly jumping back and forth between two files within a tab group.

I was trying to map this myself, but couldn't find an action that went to the last accessed tab like that.

[NewtonChutney]

Doesn't alt+1 move to the first tab like in vscode? I haven't checked if this is a keybind in vsvode/zed..

[ghuh]

The request here is not to go to the first tab, it's to go to the preview tab that you were viewing.

[NewtonChutney]

The request here is not to go to the first tab, it's to go to the *previous tab that you were viewing.

Ahh, g-a takes you to the previously accessed file buffer.. TIL!

So, it's kind of similar to vscode's default ctrl+tab, where it shows the recently accessed files first..

[ghuh]

I take this back. "pane: alternate file" basically does this so this is self map-able today!

[luccahuguet]

It seems that "yes, we are now helix"!

🔥♥️🚀🚀

#4642 (comment)

I am going to go ahead and mark this issue as completed since we've got plenty of helix keymap already implemented. FWIW I am also using it daily and so far it hasn't slowed me down in my day-to-day at Zed. If you feel otherwise, lemme know!

The work continues though, for sure

Thanks to everyone involved!

[jgarte]

Do we have debugging keybindings yet?

I tried setting a breakpoint but didn't see that SPC G b sets a breakpoint 🦆

[Malix-Labs]

Good feedback @jgarte, have you already created an issue for it ?

[jgarte]

Would also be cool to get the goto_word functionality that shows labels at each word and selects the word that belongs to the entered labels. It is mapped gw by default in Helix.

[malj]

#33580 (reply in thread)

[cor]

I find myself really missing Helix' <space>b menu which lets you fuzzy search through all currently opened buffers

[Malix-Labs]

Good feedback @cor, have you already created an issue for it ?

[luccahuguet]

hey guys and girls

which key has landed 🎉

#43618 (comment)

i wonder how to remove the vim stuff though

[luccahuguet]

Does it also work with SPACE + ? ?

good catch, it does not!

[luccahuguet]

so we need to

• create an issue for SPACE + ? (or find an existing one)
• figure out how to remove vim stuff from the which-key menu

[freepicheep]

It also doesn't work with m

[Malix-Labs]

@luccahuguet @freepicheep I created an issue for both keys: #47397

[luccahuguet]

nice, added

[Malix-Labs]

• helix: AI Agent Behavior with ENTER #47398

[Malix-Labs]

@luccahuguet, I just created #47398

[luccahuguet]

@luccahuguet, I just created #47398

perfect, sir. added it to the list

[eugenesvk]

Surround add/replace/delete was recently added, but currently buggy - removes symbols that do not surround the current object #47155

[luccahuguet]

thanks Eugenesvk

[luccahuguet]

added to list of open issues

[jnns]

The increment/decrement actions don't work for dates (YYYY-MM-DD) as they do in Helix.

Keybinding	Description	Helix command
Ctrl-a	Increment object (number) under cursor	increment
Ctrl-x	Decrement object (number) under cursor	decrement

In Helix I can increment the day or month while Zed always increments the year, no matter where the cursor is.

[luccahuguet]

good catch. would you mind opening an issue?

[jnns]

Thanks Lucca. I opened an issue here.

[luccahuguet]

added to list of open issues

[luccahuguet]

does anyone know how to remove the vim keybindings from the which-key menu?

[luccahuguet]

thanks

I wish this followed helix_mode is enabled, so we will not show vim keybinds and vice-versa

does this make sense? I could open an issue

[Malix-Labs]

Indeed an issue should be open about it (and set as blocking #47397)

[luccahuguet]

Good, I'll open it then

But I'm not sure about the blocking part so I'll leave that up to Zed

[luccahuguet]

#47467

[jgarte]

Hi, How do I get the which-key menu in Helix?

[luccahuguet]

I've stopped maintaining the open issues list because zed's tagging of helix issues with the helix label is much more comprehensive and efficient: https://github.com/zed-industries/zed/issues?q=state%3Aopen%20label%3Aarea%3Aparity%2Fhelix

in the main post, I just link to it

and frankly, why did I not do it sooner... oh well..

but if you'd like to keep posting the issues you open, here in this discussion, I think it's still helpful