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

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

Open
4 tasks done
zivarah opened this issue Aug 27, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@zivarah
Copy link

zivarah commented Aug 27, 2024

Did you check docs and existing issues?

  • I have read all the which-key.nvim docs
  • I have updated the plugin to the latest version before submitting this issue
  • I have searched the existing issues of which-key.nvim
  • 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",
    },
  },
})
@zivarah zivarah added the bug Something isn't working label Aug 27, 2024
Copy link
Contributor

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.

@github-actions github-actions bot added the stale label Sep 27, 2024
@dhruvinsh
Copy link

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

ps. commenting just to keep this issue open.

@github-actions github-actions bot removed the stale label Sep 28, 2024
Copy link
Contributor

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.

@github-actions github-actions bot added the stale label Oct 28, 2024
@zivarah
Copy link
Author

zivarah commented Oct 28, 2024

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

@github-actions github-actions bot removed the stale label Oct 29, 2024
Copy link
Contributor

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.

@github-actions github-actions bot added the stale label Nov 28, 2024
@zivarah
Copy link
Author

zivarah commented Nov 29, 2024

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

@github-actions github-actions bot removed the stale label Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants