fix(vi): stop dot-repeat recording itself#1102
Merged
Merged
Conversation
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.
. should replay the last change, but it was recording its own replay back into previous.
Each press re-wrapped previous in another Multiple, so the nesting grew by one per . (and 2. doubled the inner vec).
Observationally fine, since the engine flattens on replay, but previous grew without bound over a session.
Fix: skip recording when the command is RepeatLastAction.
. is not itself a change, so it must not update the repeat register.
The recording policy was duplicated across two arms of to_reedline_event, so this also folds it into a single record_previous helper.
The existing repeated_dot_accumulates_nesting_in_previous test pinned the buggy behavior, which got renamed and flipped to assert depth stays flat across repeated ..