bug: When the keymap is executed fast for the first time, action is not executed

s1n7ax commented 1 month ago

Did you check docs and existing issues?

[X] I have read all the which-key.nvim docs
[X] I have updated the plugin to the latest version before submitting this issue
[X] I have searched the existing issues of which-key.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.10.1

Operating system/version

NixOS

Describe the bug

Sometimes when I hit the keymaps fast for the first time, action is not executed. This occurs randomly when I open neovim. I have installed test.core in LazyVim. This is the neotest configuration I'm using. I have set 1000ms delay in which-key but removing the entire spec from the configuration did not fixed the issue either. I have set lazy = true in Lazynvim in my config which is by default false in LazyVim. I work with JavaScript and jest tests every day and I see the same issue with that as well.

In the following video, I'm working on a neotest extension. In the video, If you see errors, that means the keymap worked as expected. For the first 2 times, keymap works as expected. expected is to run the test on <space>tr. In the third time, keymap does not work when I hit it fast.

In the same session, if

I executed nmap <leader>tr command then it starts working back again.
I slowly (hit space and wait for like 500ms) and hit t and r fast, once again, it starts working again (My delay in config is 1000 so waiting til the UI is not necessary)

https://github.com/user-attachments/assets/c2c98b67-4066-4280-8c9e-0bc440d3d932

Steps To Reproduce

Clone https://github.com/s1n7ax/lazyvim-dotnvim to project
Open up a java test file or jest test file
run <leader>tr multiple times

Expected Behavior

Current test to run every single time

Health

==============================================================================
which-key: require("which-key.health").check()

- OK Most of these checks are for informational purposes only.
  WARNINGS should be treated as a warning, and don't necessarily indicate a problem with your config.
  Please |DON't| report these warnings as an issue.

Checking your config ~
- OK |mini.icons| is installed
- OK |nvim-web-devicons| is installed

Checking for issues with your mappings ~
- OK No issues reported

checking for overlapping keymaps ~
- WARNING In mode `n`, <<Tab>> overlaps with <<Tab>e>, <<Tab>m>, <<Tab>i>, <<Tab>n>:
  - <<Tab>>: Jump to right window
  - <<Tab>e>: Split top
  - <<Tab>m>: Split left
  - <<Tab>i>: Split right
  - <<Tab>n>: Split bottom
- WARNING In mode `n`, <g> overlaps with <g<C-X>>, <gc>, <gcc>, <gcO>, <gco>, <gx>, <g<C-A>>, <g%>:
  - <g>: goto
  - <g<C-X>>: Decrement
  - <gc>: Toggle comment
  - <gcc>: Toggle comment line
  - <gcO>: Add Comment Above
  - <gco>: Add Comment Below
  - <gx>: Open with system app
  - <g<C-A>>: Increment
  - <g%>: Cycle backwards through results
- WARNING In mode `n`, <c> overlaps with <cw>:
  - <c>: Dashboard-action: Config                                    
- WARNING In mode `n`, <<Space>w> overlaps with <<Space>wd>, <<C-W><C-D>>, <<Space>wm>, <<C-W><C-W>>, <<C-W><Space>>:
  - <<Space>w>: windows
  - <<Space>wd>: Delete Window
  - <<C-W><C-D>>: Show diagnostics under the cursor
  - <<Space>wm>: Enable Maximize
  - <<C-W><C-W>>: Jump to last window
  - <<C-W><Space>>: Window Hydra Mode (which-key)
- WARNING In mode `o`, <]> overlaps with <]%>:

- WARNING In mode `o`, <[> overlaps with <[%>:

- WARNING In mode `n`, <gc> overlaps with <gcc>, <gcO>, <gco>:
  - <gc>: Toggle comment
  - <gcc>: Toggle comment line
  - <gcO>: Add Comment Above
  - <gco>: Add Comment Below
- OK Overlapping keymaps are only reported for informational purposes.
  This doesn't necessarily mean there is a problem with your config.

Checking for duplicate mappings ~
- WARNING Duplicates for <> in mode `n`:
  * Split window: `{ group = true }`
  * Windows: `{ group = true }`
- WARNING Duplicates for <<C-l>> in mode `n`:
  * Go to next jump point: `{ rhs = "<C-i>zz", silent = true }`
  * Jump to previous jump point: `{ rhs = "<c-i>", silent = true }`
- OK Duplicate mappings are only reported for informational purposes.
  This doesn't necessarily mean there is a problem with your config.

Log

Following logs are from NOT working session.


Debug Started for v3.13.2
{
  commit = "6c1584eb76b55629702716995cca4ae2798a9cca"
}
new Mode(n:1)
Trigger(add) Mode(n:1) " ` ' z= g` g' , z ] [ <C-W> <Space>
on_key: <C-2>
BufNew(3)
BufReadPost(3)
BufEnter(3)
  new Mode(n:3)
BufNew(4)
Trigger(add) Mode(n:3) ' " ` z= g` g' , z ] [ <Space> <C-W> g
LspAttach(3)
  Trigger(del) Mode(n:3) g' , z ] [ ' <C-W> g " ` z= <Space> g`
new Mode(n:3)
Trigger(add) Mode(n:3) ' " ` z= g` g' , z ] [ <Space> <C-W> g
LspAttach(3)
  Trigger(del) Mode(n:3) g' , z ] [ ' <C-W> g " ` z= <Space> g`
new Mode(n:3)
BufNew(5)
Trigger(add) Mode(n:3) ' " ` z= g` g' , z ] [ <Space> <C-W> g
BufNew(6)
BufNew(7)
BufNew(8)
on_key: <Space>tr
on_key: <Esc>
on_key: <Esc>
on_key: <Space>tr
on_key: <Esc>
on_key: <Esc>
on_key: <Space>tr
on_key: <Esc>
on_key: <Esc>
on_key: <Space>tr
on_key: <Esc>
on_key: <Esc>
on_key: <C-Q>

This is from a working session

Debug Started for v3.13.2
{
  commit = "6c1584eb76b55629702716995cca4ae2798a9cca"
}
new Mode(n:1)
Trigger(add) Mode(n:1) " ` ' z= g' g` , <C-W> z [ ] <Space>
on_key: <C-2>
BufNew(3)
BufReadPost(3)
BufEnter(3)
  new Mode(n:3)
BufNew(4)
Trigger(add) Mode(n:3) " ` ' z= g' g` , <C-W> z [ ] <Space> g
LspAttach(3)
  Trigger(del) Mode(n:3) g' g` , <C-W> z [ " <Space> g ` ' z= ]
new Mode(n:3)
Trigger(add) Mode(n:3) " ` ' z= g` g' , <C-W> z [ ] <Space> g
LspAttach(3)
  Trigger(del) Mode(n:3) g' g` , <C-W> z [ " <Space> g ` ' z= ]
BufNew(5)
new Mode(n:3)
Trigger(add) Mode(n:3) " ` ' z= g` g' , <C-W> z [ ] <Space> g
on_key: <Space>tr
on_key: <CR>
BufNew(6)
BufNew(7)
BufNew(8)
on_key: <CR>
on_key: <C-Q>

Repro

No response

s1n7ax commented 1 month ago

Ok I added following to make sure it's not the plugin I'm working on.

    keys = {
        {
            '<leader>tr',
            function()
                vim.print('executing')
            end,
        },
    },

https://github.com/user-attachments/assets/a26cc2e4-8b3a-48b0-ac4a-723eab30d08a

max397574 commented 1 month ago

it would help a lot if you could try to provide a minimal repro since this problem seems only to occur in some specific cases because normally it works for most people

s1n7ax commented 1 month ago

@max397574 I have created this branch here. The keymap is <leader>tr. I have a simple print message for that.

https://github.com/s1n7ax/lazyvim-dotnvim/tree/which-key-issue

VishalSubramanyam commented 1 month ago

I'm facing this issue too. I use the default LazyVim distribution, and when I do "Leader w m" to maximize a window, it just doesn't recognize it unless I do it slowly, after which I'm able to use the keymap really fast.

cyaconi commented 2 weeks ago

Same here! When I access any file for the first time in a session, I need to wait a short amount of time after pressing the leader key, otherwise, the command executed is anything but the one I intended. For example, if I modify the opened file and quickly press ww (to save changes), the cursor moves to the Neotree panel instead of saving the file. However, if I wait a bit after pressing the leader key, the file is successfully saved. After this, the delay is no longer needed for this file only

folke / which-key.nvim