bug: Recursion Detected Error

[Spencerduran]

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)

NVIM v0.10.1

Operating system/version

Sonoma 14.5

Describe the bug

When holding j or k to navigate cursor up or down, after about 20 lines this error occurs over and over again:

"Recursion detected.
Are you manually loading which-key in a keymap?
Use opts.triggers instead.
Please check the docs."

require("which-key").setup({}) local wk = require("which-key") wk.add({ })

Steps To Reproduce

Open any file, hold j or k to scroll towards bottom of page.

Expected Behavior

No error should occur

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
- OK |nvim-web-devicons| is installed

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

BufNew(285)
  BufNew(286)
  BufNew(287)
  BufNew(288)
  BufNew(289)
  BufNew(290)
  BufEnter(289)
    new Mode(n:289)
  ModeChanged(n:i)
    new Mode(i:289)
    Unsafe(pending "<80>")
    suspend: Mode(i:289)
  Trigger(add) Mode(n:289) ' ` " g' g` z= <Plug> g z ] [ <Space> <C-W>
  Trigger(add) Mode(n:11) ' ` " g' g` z= <Plug> g z ] [ <Space> <C-W>
  BufNew(291)
  on_key: <CR>
  BufNew(292)
  on_key: c
  BufNew(293)
  on_key: o
  on_key: n
  on_key: <CR>
  on_key: w
  BufNew(294)
  on_key: k
  on_key: <CR>

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 = {} },
    -- add any other plugins here
  },
})

[max397574]

can't reproduce
are you missing something in your repro?

[leevs]

I have the same issue, when this happens when opening a file and scrolling down +50lines. It gets stuck and get
""Recursion detected.
Are you manually loading which-key in a keymap?
Use opts.triggers instead.
Please check the docs."

After downgrading to v3.10.0 I can say it's resolved and the issue seems to be in v3.11.0 - in more detail: 55fa07f

[max397574]

did you by any chance map j to something?

[Spencerduran]

For me, I have "jk" mapped to escape while in insert mode, but that's the only "j" mapping i have

local default_options = { silent = true }
------------ Insert ------------
-- Press jk fast to enter normal
map("i", "jk", "<ESC>", default_options)

the thing is, this happens with scrolling up as well

[leevs]

@max397574 you are right, I had the following bindings:

-- Remap for dealing with word wrap
-- vim.api.nvim_set_keymap('n', 'k', "v:count == 0 ? 'gk' : 'k'", { expr = true, silent = true })
-- vim.api.nvim_set_keymap('n', 'j', "v:count == 0 ? 'gj' : 'j'", { expr = true, silent = true })

However this never caused an issue before, does this somehow overload the buffer?
Removing the bindings and going back to the latest version solved it for me.

[horror-proton]

can't reproduce are you missing something in your repro?

I can reproduce it with a nvim-scrollview plugin installed

{
    "dstein64/nvim-scrollview",
    config = function()
        require('scrollview').setup({
                signs_on_startup = { 'all' }
            })
    end,
},

which for some reason causing nvim to emit ModeChange event when j was pressed in visual mode.

[Tenshikun]

I am also having the same issue.
I have j and k mapped to gj and gk resp. The only solution I have found for now is either deleting these mappings or downgrading to v3.10.0 as @leevs mentionned.

[Soooda]

For me, I use a plugin called accelerated-jk.nvim to non-linearly accelerate the browsing speed based on keys' hold time and have the below binding:

vim.keymap.set('n', 'j', '<Plug>(accelerated_jk_gj)', {})
vim.keymap.set('n', 'k', '<Plug>(accelerated_jk_gk)', {})

I also use nvim-scrollview plugin.

[Soooda]

For me, I use a plugin called accelerated-jk.nvim to non-linearly accelerate the browsing speed based on keys' hold time and have the below binding:

vim.keymap.set('n', 'j', '<Plug>(accelerated_jk_gj)', {})
vim.keymap.set('n', 'k', '<Plug>(accelerated_jk_gk)', {})

I also use nvim-scrollview plugin.

I found that actually having accelerated-jk.nvim plugin or not does not matter. But disabling the nvim-scrollview plugin solves the issue.

[GeorgeHJ]

Apologies if this is me misunderstanding, but I have also experienced this issue when holding down j or k in normal mode and this is how I seem to have solved it.

In my case, I had been using:

" Old
map j gj
map k gk

In my ftplugin script for markdown.

When I changed it to:

" New
nnoremap j gj
nnoremap k gk

The issue seems to have gone away from me in my limited testing.

Logically, my old bindings were recursive but they weren't causing me issues. Perhaps by using nnoremap and inoremap, or the lua equivalents, you can work around this one for now.

[github-actions]

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]

This issue was closed because it has been stalled for 7 days with no activity.

[Andrew15-5]

I'm also having this problem. But I think it started fairly recently, like was mentioned in #809 (comment), though I haven't tried downgrading. I can't seem to get why it happens kinda randomly. Since nowadays, I'm mostly working with Typst, I can confirm that this happens a lot when editing .typ files and tinymist LSP (and sometimes typst_languagetool LSP) is on. Since currently my script for PDF live preview is in Lua, I have to not only restart Neovim to fix the problem, but also restart the MuPDF. As a result, the entr processes are piling up in the background. I can fix everything, but it's better to not re-open Neovim every time the bug shows up. I usually work with many files opened, so re-opening everything is also a bit of a time waste.