Edit-mode roadmap: emacs, vi and helix

[kronberger-droid]

We have a scatter of issues asking for the same handful of things in the three edit modes, several of them open since 2022 and describing behaviour that has since landed. This issue collects them so there is one place to look, and closes the ones that were either done or too broad to act on.

Bugs with reproduction steps stay open as their own issues.

What each mode binds today is documented in KEYBINDINGS.md since #1197, for emacs, vi and helix.

Gaps, by mode

Vi

• replace mode (R) is not implemented at all, there is ReplaceChar for r but no sustained replace state (raised on Vi mode seems incomplete #621 in 2026)
• / and ? as in-line search are missing, ? currently searches history rather than the buffer, and neither works as a motion (from Vi multi-character search within line #931). Best as an option, since ? as history search is what zsh does and it would have to move.
• redo has no key in normal mode, since Ctrl-r is history search in every mode. EditCommand::Redo exists and can be bound, there is just no default. (from Vi multi-character search within line #931)
• paragraph text objects (ip, ap) are the one text-object family Vi mode text objects for word, WORD, brackets and quotes #939 did not cover
• ca(, ca[, ca{ and ca" do nothing, since the change-around branch of the parser skips the explicit bracket and quote chars that da( and ya( handle. cab and caq work.
• system clipboard for the vi registers, along the lines of vim's clipboard^=unnamedplus, so yank, delete and put reach the system clipboard rather than only the internal cut buffer. Opt-in and off by default, since sharing every d and x would surprise people. The other route raised in the thread is real registers with "+. (from Give vi_normal mode's cut/paste access to the system clipboard #745)
• history navigation in normal mode loses its place once the cursor moves (from vi keybinds are wrong and/or inconsistent with readline #788). vi: cursor position semantics are not mode-aware (root cause of multiple off-by-one bugs) #1066 fixed the mode-aware cursor root cause and the word boundaries follow vi rules now, so Esc stepping back, punctuation and resting on the last char are all done. What is left is that any cursor move ends the history traversal, so k h j and k h k start over from the newest entry instead of continuing from the item you were on. The same issue asks for k to put the cursor at the start of the recalled line as bash does, today it is always the end of the first line, which is also what Cursor position after up arrow history cycling is unconventional on multi-line statements #999 is about.
• completing history hints from normal mode with e, E, A and friends (from Vi-mode (Normal mode) completing suggestions #925). l, Right, End and Ctrl-e already take the whole hint and Ctrl-Right takes it word by word, but none of the vi motion keys do.

Emacs

• the keybinding gaps in Request for additional keybindings #619 are mostly configurable today, but the defaults are worth another pass against readline
• Ctrl+Left and Ctrl+Right should stop at punctuation, and the word-break characters should be configurable (from Request for additional keybindings #619). Emacs and the shared bindings still move by unicode words, so some.long.string is one word. The vi-rule word motion exists, it is just not what these keys use.

Helix

• the commands KEYBINDINGS.md lists as not yet available: ;, ,, J, G, X, >, <, the / n N search family, m match mode and multi-cursor (multi-cursor was first asked for on Feature Vision Discussion: Keybindings #69)

Cross-cutting

These are not per-mode, they are missing machinery that several modes want.

• chords and multi-key sequences, wanted for jk to leave insert mode (from Discussion: will reedline become a full-fledged "text editor?" #853), for ctrl+x e (from Open current line in editor with ctrl+x e #654), and for helix's g family to stop being special-cased. feat: Allow for user-defined "chord" / multi-key keybindings (and correct vi motions when targeting <space> char) #1016 and feat: add initial support for multi-stroke chord keybindings in emacs mode #989 both took a run at it and were closed, the combined design is in Chord keybindings: one shared resolver over a trie #1204.
• until only falls through on events that report failure, and most edit commands never do. Cursor moves that go nowhere (fix: let no-op cursor moves fall through #1208) and a copy without a selection (feat(editor): make copy selection report failure without selection #1166) report it now, text edits that change nothing still count as handled. That one stays tracked in Handle more events for until keybindings #876.
• cuts that accumulate, which is missing in two places. In emacs repeated Ctrl+W should collect into one buffer and a non-kill action resets it, as zsh does (from Accumulating cut/paste like zsh in emacs mode #896, Cut/Yank multiple words #631 tried it). In vi a counted delete runs as separate cuts that each overwrite the buffer, so 3dw then P gives back one word instead of three.
• a leader key in vi normal mode, so users can bind sequences that do not collide with the built-in commands (from Support VIM style keybindings with custom leader key in VIM normal mode #1064)
• langmap, mapping a non-qwerty layout or a non-Latin script like Cyrillic or Greek onto the normal-mode commands without rebinding each one (from langmap option for vi normal mode #978)
• argument-wise motions and kills rather than word-wise, so M-f can step over "a long quoted argument" as one unit and M-d can delete it. This needs host tokenisation, so it likely wants a trait rather than a built-in. A primitive that returns the span of the argument under the cursor would already do for the reporter. (from Navigating by-argument in addition to by-word #669)

Staying Open

Reproducible bugs, which should be fixed on their own rather than tracked here:

• Move(Big)WordRightEnd is off-by-1 in insert mode #766 Move(Big)WordRightEnd is off by one in insert mode
• Vi Normal movement key rebind break the visual/select mode. #1007 rebinding a vi normal movement key breaks visual and select mode
• Unbinding Shift+I does not appear to do anything #1008 unbinding Shift+I has no effect
• vichangemode fails to switch to normal mode after executehostcommand #1070 vichangemode does not switch after executehostcommand
• HistoryHint(Word)Complete events don't work in Helix Normal mode #1185 history hints in helix normal mode. The events and Right work since fix(helix): count the resting block caret as end of buffer #1192, l still does not take the hint the way vi's l does.
• #TBD Esc does not leave Ctrl-r history search in vi and helix mode (first reported on Vi mode seems incomplete #621)

Closing

Closing into this issue: #382, #619, #621, #669, #745, #788, #853, #896, #925, #931, #978, #1064.

[glcraft]

I see some interesting features right there!

About the case "ca(, ca[, ca{ and ca" do nothing", I noticed that it works well with #1188 :

Enregistrement.de.l.ecran.2026-09-25.a.14.13.48.mov

In this video, once I wrote a test input, I went in the beginning with ^, and I tapped ca(. After that, I tried ci( that works well too.

Since I unified text object's behavior around the TextObject struct, the commands behind c/d/y/v and so on share the same code.