fix(vim): start in INSERT mode when buffer is empty

[314clay]

Summary

• When vim mode is enabled with an empty input buffer, start in INSERT mode instead of NORMAL mode
• Auto-switch to INSERT mode when buffer becomes empty (e.g., after submitting a command)
• This improves UX by allowing immediate typing when there's no content to navigate

Background

In NORMAL mode with an empty buffer, there's nothing to navigate or edit, making it pointless to start there. Users had to always press i first before being able to type.

Changes Made

• VimModeContext.tsx: Initialize vim mode to INSERT instead of NORMAL
• vim.ts: Added useEffect to auto-switch to INSERT when buffer is empty
• vim.test.tsx: Updated tests to reflect the new default behavior

Test plan

• All existing vim tests pass
• npm run preflight passes
• Manual testing: Enable vim mode, verify it starts in INSERT mode
• Manual testing: Type a command, submit, verify cursor returns to INSERT mode

Fixes #15530

🤖 Generated with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Summary of Changes

Hello @314clay, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the user experience for Vim mode users by making the initial state and subsequent behavior more intuitive when interacting with empty input buffers. By defaulting to INSERT mode and automatically switching to it when the buffer clears, it removes an unnecessary step for users who primarily intend to type, streamlining their workflow in the CLI.

Highlights

• Default Vim Mode for Empty Buffer: When Vim mode is enabled and the input buffer is empty, the system will now start directly in INSERT mode instead of NORMAL mode. This allows users to type immediately without needing to press 'i'.
• Auto-Switch to INSERT Mode: The system will automatically switch to INSERT mode if the buffer becomes empty (e.g., after submitting a command), ensuring a seamless typing experience.
• Test Updates: Existing Vim tests have been updated to reflect the new default behavior, including a new test case for auto-switching to INSERT mode when the buffer is empty.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to improve the user experience for vim mode by starting in INSERT mode on an empty buffer. The changes correctly identify the need to switch modes based on buffer content and add a useEffect in the useVim hook to handle this.

However, the current implementation makes vim mode always start in INSERT mode, regardless of whether the buffer is empty or not. This might be unexpected for vim users who are used to starting in NORMAL mode to navigate existing content.

My review includes suggestions to adjust the implementation to start in NORMAL mode by default, and only switch to INSERT mode if the buffer is empty. This aligns better with the pull request's title and description, and provides a more conventional vim experience. These changes involve reverting the initial state defaults to 'NORMAL' and centralizing the mode-switching logic within the useVim hook.

[gemini-code-assist]

The PR description implies that vim should start in INSERT mode only when the buffer is empty. This change makes it always start in INSERT mode, which might be unexpected for vim users editing a non-empty buffer, who would typically expect to start in NORMAL mode to navigate.

To better match the described behavior, this should probably be initialized to 'NORMAL'. The useEffect in the useVim hook will then correctly switch to 'INSERT' mode if the buffer is empty.

Suggested change

	const [vimMode, setVimMode] = useState<VimMode>('INSERT');
	const [vimMode, setVimMode] = useState<VimMode>('NORMAL');

[gemini-code-assist]

This unconditionally sets the mode to INSERT when vim is enabled via this toggle function. This is inconsistent with enabling vim through other means (e.g., a settings file change) and contributes to the issue of always starting in INSERT mode, even with a non-empty buffer.

It would be better to remove this logic and let the useVim hook, which has access to the buffer's content, decide the appropriate initial mode. The new useEffect in vim.ts already handles switching to INSERT mode for empty buffers.

[gemini-code-assist]

Consistent with the other comments, the initial mode for the vim state reducer should be 'NORMAL'. The useEffect you've added will then correctly switch to 'INSERT' mode if the buffer is empty, achieving the behavior described in the PR.

Suggested change

	mode: 'INSERT',
	mode: 'NORMAL',

[galz10]

Hey, @314clay!

I totally get the UX logic here, it definitely saves a keystroke to drop right into Insert mode when the buffer is empty. However, our goal for Vim mode is parity with the actual editor.

Since standard Vim always defaults to Normal mode (even when opening a brand new file), we want to stick to that behavior to match the muscle memory users expect. We try not to deviate from how Vim works unless absolutely necessary.

I'm going to close this out, but really appreciate the contribution!

[gitenstuff]

@galz10
@314clay
Since standard Vim always defaults to Normal mode (even when opening a brand new file), we want to stick to that behavior to match the muscle memory users expect. We try not to deviate from how Vim works unless absolutely necessary.

This misses the mark: Vim mode is not a vim editor, it is merely an input mode for command line interaction that leverages select vim editing features that are indeed part of muscle memory of regular vim users.

The distinction is crucial.

The impetus for vim mode should be to mimic Bash's implementation of vim mode. Bash vim mode starts in Insert mode for the very reason this fix resolves: More often than not, users will want to type a bash command rather than navigate.

Users of bash vim mode do not "expect" that the mode will mimic Vim, but instead expect it to mimic Bash vim mode: Starting in vim mode is NOT consistent with their Bash vim mode muscle memory.

Bash vim mode when in Normal mode enables history navigation, e.g., k, j, which gemini-cli vim mode does not support. It also supports 'dd' for quick erasure. For sure, bash vim mode does not seek to emulate Vim editor and that is clearly stated within the Bash docs.

This fix partially aligns gemini-cli vim mode with Bash vim mode which I assert is what users of this feature would expect.

In summary, perhaps the greater issue is to revisit the motivation for gemini-cli vim mode to determine whether it's goal is to emulate Vim editor (No one expects that) or to emulate Bash vim mode.

[gitenstuff]

/open

[galz10]

The added useEffect creates a "trap" that prevents users from staying in NORMAL mode when the buffer is empty. If a user clears the buffer (e.g., via dd), the effect immediately forces the mode to INSERT. If the user attempts to switch back to NORMAL mode (by pressing Esc) the effect triggers again, forcing them back to INSERT. This effectively disables Normal mode commands for empty buffers.Remove the useEffect block entirely. The initialization changes in VimModeContext.tsx and vim.ts are sufficient to ensure the user starts in INSERT mode. Since command submission (which clears the buffer) typically occurs in INSERT mode, the user will naturally remain in INSERT mode for the next command without this enforcement.

[galz10]

Hi @gitenstuff Thank you for the feedback. You are absolutely correct; my understanding of the design goal for Vim mode missed the mark. I agree that aligning with the behavior of Bash's Vim mode, where starting in Insert mode is the standard, is much more intuitive for a command-line interface. I have reopened the PR to reflect this correction and added my review.

@314clay please make sure to address the comment and sign the CLA