Fix gb repeat count persisting across subsequent calls#9941
Closed
danielalanbates wants to merge 1 commit intoVSCodeVim:masterfrom
Closed
Fix gb repeat count persisting across subsequent calls#9941danielalanbates wants to merge 1 commit intoVSCodeVim:masterfrom
gb repeat count persisting across subsequent calls#9941danielalanbates wants to merge 1 commit intoVSCodeVim:masterfrom
Conversation
) When using `gb` with a count (e.g. `5gb`), the count was persisting in the RecordedState for subsequent `gb` calls without a count. This caused `5gb gb` to create 10 cursors instead of the expected 6, because the RecordedState is only reset when returning to Normal mode, but `gb` enters Visual mode. Reset `recordedState.count` after `execCount` completes so the count is consumed by the command that specified it and does not leak into subsequent invocations. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Author
|
Thank you for your time reviewing this. We're withdrawing this PR. Apologies for any inconvenience. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #4075
When using
gbwith a count (e.g.5gb), the count persists in theRecordedStatefor subsequentgbcalls that don't specify a count. This causes5gb gbto create 10 cursors instead of the expected 6.Root cause:
gb(ActionOverrideCmdD) hasrunsOnceForEachCountPrefix = true, which causesexecCountto repeatexecbased onvimState.recordedState.count. However,gbtransitions into Visual mode, andRecordedStateis only reset when returning to Normal mode (inmodeHandler.tsline ~891). So the count from5gbleaks into the nextgbinvocation.Fix: Override
execCountinActionOverrideCmdDto resetrecordedState.countto0after the parentexecCountcompletes. This ensures the count is consumed by the command that specified it and defaults back to 1 for subsequent calls without an explicit count.Test plan
5gbon a word with 5+ occurrences should select 5 additional occurrences (6 total cursors) - unchanged behavior5gb, pressinggbagain (without a count) should add exactly 1 more cursor (7 total) - previously it added 5 more3gb gb gbshould create 5 total cursors (1 original + 3 from count + 1 + 1) - previously created 10gbwithout any count should still work as before (add 1 cursor per invocation)<D-d>(Cmd+D on macOS) should continue to work identically togbThis PR was created with the assistance of Claude Opus 4.6 by Anthropic. Happy to make any adjustments! Reviewed and submitted by a human.