bug: Recursion Detected Error
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
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
},
})
can't reproduce are you missing something in your repro?
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: https://github.com/folke/which-key.nvim/commit/55fa07fbbd8a4c6d75399b1d1f9005d146cda22c
did you by any chance map j to something?
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
@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.
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.
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.
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-scrollviewplugin.
For me, I use a plugin called
accelerated-jk.nvimto 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-scrollviewplugin.
I found that actually having accelerated-jk.nvim plugin or not does not matter. But disabling the nvim-scrollview plugin solves the issue.
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.
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.
This issue was closed because it has been stalled for 7 days with no activity.
I'm also having this problem. But I think it started fairly recently, like was mentioned in https://github.com/folke/which-key.nvim/issues/809#issuecomment-2277834227, 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.