VIM Support that feels complete and consistent to VIM users

[jacob314]

[scidomino]

I had gemini look for possible duplicates:

Most Relevant Potential Duplicates:

• #15536: Enhance Vim Mode with Visual Mode, Registers, and Advanced Text Objects - This is the most direct functional duplicate, requesting the same
  high-level enhancements.
• #15618: Vim mode should align with Bash vim mode, NOT Vim editor - A related philosophical discussion on how "consistent" Vim support should be
  implemented (Bash vs. pure Vim).

Related Specific Feature Requests:
The following issues describe specific gaps in Vim support that likely fall under the scope of "complete and consistent" support:

• #16768: Add support for "big word" movements in Vim mode.
• #15988: VIM does not support delete till end of line (d$).
• #14689: In VIM keyboard emulation mode, CTRL+[ does not act like ESC.
• #14564: Vim navigation allowing user to navigate the output of the cli.
• #13586: Prevent Esc from cancelling Gemini action when in Vim Insert mode.
• #17380: ctrl-u does nothing in vi mode.

[skarzi]

I have also found some more issues:

1. Undo (u) commands are blocked in Normal mode.

   The u key currently has no explicit handler in the Normal mode logic. It falls through to a default case that marks the key as "handled" without performing any action, effectively consuming the key and preventing the TextBuffer from receiving the undo command.

2. The d operator misses support for h/j/k/l motions.

   While the delete operator works for word-based motions like dw, it fails for basic direction keys. The handlers for h, j, k, and l do not check for a pending delete operator, so commands like dh or dl simply move the cursor without deleting any text.

3. Broken cc (change line) command behavior.

   The cc implementation uses offset calculations that incorrectly include newline characters or exceed line boundaries. This results in either the entire line structure being deleted (merging it with the next line) or the operation being rejected by internal range validation.

4. Vertical change-move commands (cj / ck) fail silently.

   These commands fail because the logic computes target positions in terms of UTF-16 code unit lengths, whereas the buffer validates changes using Unicode code point lengths. This mismatch causes the internal buffer to reject the edit as an "out of bounds" operation.

5. The gg command ignores count prefixes.

   The handler for the g key immediately clears any numerical count on the first press. As a result, a command like 5gg (which should go to line 5) is interpreted as a standard gg, always moving the cursor to the first line.

6. Unicode/Emoji handling errors in coordinate calculations.

   Multiple functions, including getPositionFromOffsets and getLineRangeOffsets, rely on standard JavaScript string length instead of proper code point counts. This causes cursor drift and incorrect deletion ranges whenever emojis or multi-byte characters are present in the buffer.

7. Broken operators with non-standard motions (d$, d0, dG, dgg)

   Motion commands such as 0, $, ^, G, and gg perform cursor movement but do not check for a pending operator. If a user types d$, the cursor moves to the end of the line, but the delete action is never performed.

8. Dangling or "stuck" operator state.

   If a pending operator (like d) is set and the user presses an unhandled motion key (like h), the state is not cleared. This causes the next valid motion, like w, to unexpectedly trigger the previous delete command.

9. x at the end of a line leaves the cursor in an invalid position.|

   When deleting the last character on a line containing x, the cursor does not move back to the new last character. It remains at its old index, one position past the end of the line—an invalid state in Normal mode.

10. D and C commands ignore the repeat count.

    The handlers for "Delete to End of Line" (D) and "Change to End of Line" (C) are hardcoded to affect only one line. They should instead respect the prefix count to allow deleting or changing across multiple lines.

11. preferredCol is not preserved during vertical movement
    When moving vertically with j or k, the implementation resets the "preferred column" to null. This prevents the cursor from remembering its original horizontal position when moving across lines of varying lengths.

12. The Double-Escape timer is not reset by intervening commands.
    The context-clearing "double-escape" feature only updates its timestamp when the Escape key is pressed. If a user presses Escape, moves the cursor, and then presses Escape again within 500ms, the context is cleared even though a command was executed in between.

13. The $ command ignores count prefixes.
    In standard Vim, 2$ moves the cursor to the end of the following line. Currently, the $ handler ignores the count entirely and only moves the cursor to the end of the current line.

14. ^ motion on whitespace-only lines moves the cursor past the end.
    If a line consists only of spaces or tabs, the ^ command moves the cursor to a position equal to the line length. This places the cursor one index beyond the last valid character.

15. Count prefix before the repeat command (.) is ignored.
    The repeat command should respect a new count prefix (e.g., 3. should repeat the last action three times). Currently, it ignores the new prefix and only uses the count from the original command.

[skarzi]

What's the current state of working on Gemini Vim-mode? Do you have a process?
Can I simply take one issue from any Vim-mode-related one, resolve it, and post a PR here for review?

[scidomino]

@skarzi check out CONTRIBUTING.md for the details. You can assign yourself to any bug with the help-wanted label.

[ppgranger]

/assign