fix: preserve queued keys at picker launch (#2274) #2625
Merged
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.
Description
Ensure that any keystrokes that are queued at picker launch are processed only after the picker's mode (
insert
ornormal
) has been chosen, preserving their intended meaning.Previously the picker's mode was set by simulating keystrokes via
nvim_feedkeys(simulated_keypresses, "n")
. In the absence of queued keystrokes, this works fine; but if the user is able to queue keystrokes before the call tonvim_feedkeys()
, those queued keystrokes are processed before the simulated keystrokes that change the picker's mode. Because of this unexpected ordering, the user's queued keystrokes may appear to be ignored or may cause the picker to start in the wrong mode.For example, consider the below normal-mode mapping:
Upon launching the picker via
<space>ff
, Neovim is already in normal mode. To switch to insert mode in the picker, Telescope previously used a call tonvim_feedkeys("A", "n")
, simulating a keypress ofA
to enter insert mode at the end of the current line. ThisA
would not be processed until all previously queued user keystrokes have been processed, causing issues.In real-world use, problems occur when the user types
<space>ff
followed quickly by characters intended as fuzzy match text. This can be demonstrated usingnvim_feedkeys()
as shown below.The user intended to search for
apple
, but thea
is misinterpreted as a request to enter insert mode at end of line, after whichpple
is inserted; subsequently, Telescope's simulatedA
is then appended, resulting in a search string ofppleA
.To ensure that Telescope's simulated keypresses are processed first, an additional
i
flag is now passed tonvim_feedkeys()
, causing the simulated keypresses to be inserted at the start of the typeahead buffer ahead of any user keystrokes.Fixes #2274.
Type of change
How Has This Been Tested?
:call nvim_feedkeys()
as explained aboveConfiguration:
Neovim version (nvim --version):
Operating system and version:
Checklist: