bug: 568b841 (refactor: presets, 2024-07-09) breaks vim-fugitive commit bindings unless you're very fast

[zivarah]

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)

v0.10.1

Operating system/version

MacOS 14.6.1, Windows 11, NixOS

Describe the bug

I noticed recently that while using fugitive's status buffer, the fixup commit bindings (cf and cF) only worked if I was fairly quick hitting the f/F. If I was too slow, then which-key shows "move to next char" instead of the fugitive binding like it normally does, and hitting f/F after that doesn't work (I'm getting an E21: Cannot make changes, 'modifiable' is off error if I actually try to perform the "move to next char" action, oddly).

I was able to isolate this to which-key, to my surprise. A bisect shows that it is specifically 568b841 (refactor: presets, 2024-07-09), though this is still reproducible on the current head of main: 6c1584e (chore(main): release 3.13.2 (#796), 2024-07-24).

Steps To Reproduce

1. Open up nvim using the reproduction config below. Note that you'll need to switch to a directory that is a valid git repo in order to load the fugitive status buffer.
2. Open the fugitive status buffer with :G
3. Hit cf quickly and see that the command line is populated with :Git commit --fixup= as expected
4. Hit c and wait for which-key to show up. Note that which-key shows f => move to next char instead of the fugitive binding
5. Hit f, and see that the fixup commit command is not teed up

Expected Behavior

When in the fugitive status buffer, c followed by f should tee up a fixup commit regardless of the delay between the two keystrokes and whether or not which-key shows up.

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 ~
- WARNING |mini.icons| is not installed
- WARNING |nvim-web-devicons| is not installed
- WARNING Keymap icon support will be limited.

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

checking for overlapping keymaps ~
- WARNING In mode `n`, <gc> overlaps with <gcc>:
  - <gc>: Toggle comment
  - <gcc>: Toggle comment line
- 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 ~
- OK No duplicate mappings found

Log

Debug Started for v3.13.2
{
  branch = "main",
  commit = "6c1584eb76b55629702716995cca4ae2798a9cca"
}
new Mode(n:1)
Trigger(add) Mode(n:1) ` ' " g' g` z= g <C-W> <Plug> z [ ]
on_key: :
ModeChanged(n:c)
  new Mode(c:1)
  Safe(true)
Trigger(add) Mode(c:1) <C-R>
on_key: G
on_key: <CR>
ModeChanged(c:n)
  Unsafe(command-mode)
  suspend: Mode(n:1)
  Trigger(del) Mode(n:1) g <C-W> <Plug> z [ ] ` ' " g' g` z=
BufNew(4)
BufReadPost(4)
BufEnter(4)
  new Mode(n:4)
Trigger(add) Mode(n:1) ` ' " g' g` z= g <C-W> <Plug> z [ ]
Trigger(add) Mode(n:4) ` ' " z= g' g` [ <C-W> <Plug> z ] g cz cb cR cr co cm cv
on_key: c
ModeChanged(n:no)
  new Mode(o:4)
  Safe(true)
  State(start): Mode(o:0) Node() { defer = false }
    update Mode(o:4)
    continue:  Mode(o:4)
    getchar
    Trigger(add) Mode(o:4) g [ ]
    on_key: f
    got: f
    suspend: Mode(o:4)
    Trigger(del) Mode(o:4) ] [ g
    feedkeys: Mode(o:4) f
on_key: f
on_key: <Esc>
ModeChanged(no:n)
  Safe(true)
Trigger(add) Mode(o:4) g [ ]
on_key: :
ModeChanged(n:c)
  new Mode(c:4)
  Safe(true)
Trigger(add) Mode(c:4) <C-R>
on_key: q
on_key: a
on_key: <CR>
ModeChanged(c:n)
  Unsafe(command-mode)
  suspend: Mode(n:4)
  Trigger(del) Mode(n:4) ` ' " z= g' g` [ <C-W> <Plug> z ] g cz cb cR cr co cm cv
Trigger(add) Mode(n:4) ` ' " z= g' g` [ <C-W> <Plug> z ] g cz cb cR cr co cm cv

Repro

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
  spec = {
    {
      "folke/which-key.nvim",
      opts = { debug = true, },
      commit = "6c1584eb76b55629702716995cca4ae2798a9cca",
    },
    {
      "tpope/vim-fugitive",
      config = function() end,
      commit = "0444df68cd1cdabc7453d6bd84099458327e5513",
    },
  },
})

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[dhruvinsh]

I'm facing the similar issue. unless there is solution available.

ps. commenting just to keep this issue open.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[zivarah]

Still running into this: commenting to remove the stale tag.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[zivarah]

Still running into this: commenting to remove the stale tag again.

[folke]

When pressing c and timeoutlen is expired, you enter operator pending mode for c. If you press ct fast, then you execute a normal mode mapping instead.

So this all works exactly how it should.

Before the rewrite, which-key actually did this incorrectly. With the rewrite, this has been fixed...

[zivarah]

Oh, you're totally right. I'm sorry, I should have tested this without which-key installed at all before opening this issue. I was focused on the change without realizing that it was the original behavior that was broken.