which-key.nvim bug: Breaks vim.v.count in visual mode

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)

0.10.1

Operating system/version

macos 14

Describe the bug

vim.v.count doesn't work in visual mode(seems to only happen when 2 or more lines are selected).

Steps To Reproduce

Repro config attached.

Vj5<leader>M
:messages
count 0
Comment out which-key config, restart nvim
Vj5<leader>M
:messages
count 5

Expected Behavior

vim.v.count should be available to function handling visual mode mapping

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) ` ' " z= g` g' z <C-W> g [ ]
on_key: V
ModeChanged(n:V)
  new Mode(x:1)
  Safe(true)
  State(start): Mode(x:0) Node() { defer = true }
    update Mode(x:1)
    continue:  Mode(x:1)
    getchar
    Trigger(add) Mode(x:1) " <C-W> <Space> g ] z [
    on_key: j
    got: j
    suspend: Mode(x:1)
    Trigger(del) Mode(x:1) " <C-W> <Space> g ] z [
    feedkeys: Mode(x:1) j
on_key: j
Trigger(add) Mode(x:1) " <C-W> <Space> g ] z [
on_key: 5
on_key: <Space>
State(start): Mode(x:0) Node(<Space>) { keys = "<Space>" }
  update Mode(x:1)
  continue: <Space> Mode(x:1)
  getchar
  on_key: M
  got: M
  suspend: Mode(x:1)
  Trigger(del) Mode(x:1) " <C-W> <Space> g ] z [
  feedkeys: Mode(x:1) <Space>M
on_key: <Space>M
Trigger(add) Mode(x:1) " <C-W> <Space> g ] z [
on_key: <Esc>
ModeChanged(V:n)
  Safe(true)
on_key: :
ModeChanged(n:c)
  new Mode(c:1)
  Safe(true)
Trigger(add) Mode(c:1) <C-R>
on_key: m
on_key: s
on_key: <BS>
on_key: e
on_key: s
on_key: s
on_key: a
on_key: g
on_key: e
on_key: s
on_key: <CR>
ModeChanged(c:n)
  Unsafe(command-mode)
  suspend: Mode(n:1)
  Trigger(del) Mode(n:1) " z= g` g' z <C-W> g [ ] ` '
Trigger(add) Mode(n:1) ` ' " z= g` g' z <C-W> g [ ]
on_key: :
ModeChanged(n:c)
  Safe(true)
on_key: q
on_key: <CR>
ModeChanged(c:n)
  Unsafe(command-mode)
  suspend: Mode(n:1)
  Trigger(del) Mode(n:1) " z= g` g' z <C-W> g [ ] ` '
Trigger(add) Mode(n:1) ` ' " z= g` g' z <C-W> g [ ]

Repro

local lazypath = "/tmp/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system { "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", "--branch=stable", lazypath }
end
vim.opt.rtp:prepend(lazypath)
vim.opt.termguicolors = true
vim.g.mapleader = " "
vim.g.maplocalleader = " "


require("lazy").setup ({
    {
        "folke/which-key.nvim",
        config = function()
            require("which-key").setup {}
        end,
    },
}, { root = "/tmp/lazy" })

vim.keymap.set("x", "<leader>M", function()
  print("count " .. vim.v.count)
end)

Aug 17 '24 22:08 pejrich

I can confirm: I think it started happening since v3 It breaks tpope's vim-unimpaired [e/]e to move selection up or down by N lines; can only move one line now, regardless of count, and then can dot-repeat as needed. Disabling which-key makes it work as expected again.

This can also be seen visually:

with which-key disabled and 2 lines visually selected, first I see 2 in the right bottom corner (as 2 lines are selected). Typing 3] shows ]3 in there (meaning the ]3 is pending operator), then e moves the selection by 3 lines;
enabling which-key and trying to reproduce the same steps above: as soon as ] is pressed after 3, which-key panel shows up, but corner shows 2 again, i.e. 3] operation is dismissed/reset, and then e moves just 1 line, instead of 3

Sep 12 '24 19:09 andrevmatos

I believe I'm facing the same issue, with g<C-a> in visual block mode.

git bisect found e6beb8845e80558194c6027b7a985e1211e76878 to be the offending commit. When I re-add the code in buf.lua -> Mode:attach(), vim.v.count works again.

The added code:

  -- FIXME:
  if self.mode:find("[xo]") then
    return
  end

Adding the same code in the same place on main (v3.13.3) still fixes the problem.

I'm not sure what the ramifications of this are, though.

Sep 24 '24 14:09 ktprograms

Upon further digging, this commit https://github.com/folke/which-key.nvim/commit/e4d54d11cc247edd0ed4bde7a501caa8e119c1ff appears to be both the cause and the solution.

Handling for vim.v.count and vim.v.register is added here, but only for non x or o modes.

Changing to an if true then makes it work. I don't know enough about the internals of neovim modes or which-key, so I'm not sure why this is here or what breaks when removing the check.

Sep 25 '24 17:09 ktprograms

As a workaround, until count is fixed for x (visual) mode, one can disable the triggers in this mode in config:

require('which-key').setup({
  ...
  triggers: {
    { "<auto>", mode = "nsot" },
  },
})

Oct 02 '24 20:10 andrevmatos

@andrevmatos Thank you, this fixed it for me. (It should be triggers = rather than triggers: , but I knew what you meant). I assume the only implications of this change are that WK won't show up in visual mode? I can live with that.

Oct 13 '24 11:10 pejrich

This change breaks a typical work flow of writing the code, and send code to REPL.

The scenario is, I have multiple REPLs opened, and I will send the visually selected content to different REPL using the vim.v.count, e.g. (2<Leader>s) will send the visually selected content to 2nd REPL. With this breaking change, the code will always send to the first REPL.

Until this issue is fixed, other than disable which-key in visual mode (as I also want to use which-key in visual mode), an alternative way is to bind the command to a key sequence that will not trigger which key, like <A-s>.

Nov 11 '24 07:11 milanglacier

I have the same issue here where I use vim.v.count in visual mode mapping.