Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: preserve queued keys at picker launch (#2274) #2625

Merged
merged 1 commit into from
Jul 29, 2023
Merged

fix: preserve queued keys at picker launch (#2274) #2625

merged 1 commit into from
Jul 29, 2023

Conversation

drmikehenry
Copy link
Contributor

Description

Ensure that any keystrokes that are queued at picker launch are processed only after the picker's mode (insert or normal) 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 to nvim_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:

:nnoremap <space>ff :Telescope find_files<CR>

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 to nvim_feedkeys("A", "n"), simulating a keypress of A to enter insert mode at the end of the current line. This A 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 using nvim_feedkeys() as shown below.

:call nvim_feedkeys("\<space>ff" . "apple")

The user intended to search for apple, but the a is misinterpreted as a request to enter insert mode at end of line, after which pple is inserted; subsequently, Telescope's simulated A is then appended, resulting in a search string of ppleA.

To ensure that Telescope's simulated keypresses are processed first, an additional i flag is now passed to nvim_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

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

  • Tested interactively and via :call nvim_feedkeys() as explained above

Configuration:

  • Neovim version (nvim --version):

    NVIM v0.9.1
    Build type: Release
    LuaJIT 2.1.0-beta3
    
       system vimrc file: "$VIM/sysinit.vim"
      fall-back for $VIM: "/__w/neovim/neovim/build/nvim.AppDir/usr/share/nvim"
    
    Run :checkhealth for more info
    
  • Operating system and version:

    $ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 22.04.2 LTS
    Release:        22.04
    Codename:       jammy
    

Checklist:

  • My code follows the style guidelines of this project (stylua)
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation (lua annotations)

Ensure that any keystrokes that are queued at picker launch are
processed only after the picker's mode (`insert` or `normal`) 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 to `nvim_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:
```vim
:nnoremap <space>ff :Telescope find_files<CR>
```

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 to `nvim_feedkeys("A", "n")`, simulating a keypress of `A` to
enter insert mode at the end of the current line.  This `A` 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 using `nvim_feedkeys()` as shown below.

```vim
:call nvim_feedkeys("\<space>ff" . "apple")
```

The user intended to search for `apple`, but the `a` is misinterpreted
as a request to enter insert mode at end of line, after which `pple` is
inserted; subsequently, Telescope's simulated `A` is then appended,
resulting in a search string of `ppleA`.

To ensure that Telescope's simulated keypresses are processed first, an
additional `i` flag is now passed to `nvim_feedkeys()`, causing the
simulated keypresses to be inserted at the start of the typeahead buffer
ahead of any user keystrokes.

Fixes #2274.
@drmikehenry
Copy link
Contributor Author

See additional discussion in #2618.

@jamestrew jamestrew merged commit b6fccfb into nvim-telescope:master Jul 29, 2023
6 checks passed
Conni2461 pushed a commit that referenced this pull request Sep 5, 2023
Ensure that any keystrokes that are queued at picker launch are
processed only after the picker's mode (`insert` or `normal`) 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 to `nvim_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:
```vim
:nnoremap <space>ff :Telescope find_files<CR>
```

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 to `nvim_feedkeys("A", "n")`, simulating a keypress of `A` to
enter insert mode at the end of the current line.  This `A` 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 using `nvim_feedkeys()` as shown below.

```vim
:call nvim_feedkeys("\<space>ff" . "apple")
```

The user intended to search for `apple`, but the `a` is misinterpreted
as a request to enter insert mode at end of line, after which `pple` is
inserted; subsequently, Telescope's simulated `A` is then appended,
resulting in a search string of `ppleA`.

To ensure that Telescope's simulated keypresses are processed first, an
additional `i` flag is now passed to `nvim_feedkeys()`, causing the
simulated keypresses to be inserted at the start of the typeahead buffer
ahead of any user keystrokes.

Fixes #2274.

(cherry picked from commit b6fccfb)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Async Opening Misses Keypresses
2 participants