bug: <C-r> is not showing the contents of the register in telescope prompt

[yavorski]

Did you check docs and existing issues?

• I have read all the which-key.nvim docs
• 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.0

Operating system/version

Linux

Describe the bug

In previous version, when you were in telescope prompt pressing <C-r> in insert mode would show the which-key with the contents of the registers. Now this is showing something else.

Steps To Reproduce

1. Open Telescope - find files for example
2. Enter insert mode
3. Press <C-r> to show the contents of registers, in order to select something

Expected Behavior

Show the contents of the register as before update

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.
- 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 `o`, <i> overlaps with <ii>:
  - <i>: inside
  - <ii>: Object scope
- WARNING In mode `o`, <a> overlaps with <ai>:
  - <a>: around
  - <ai>: Object scope with border
- WARNING In mode `x`, <i> overlaps with <ii>:
  - <i>: inside
  - <ii>: Object scope
- WARNING In mode `x`, <a> overlaps with <ai>, <a%>:
  - <a>: around
  - <ai>: Object scope with border
- WARNING In mode `n`, <gc> overlaps with <gcc>:
  - <gc>: Comment
  - <gcc>: Comment line
- WARNING In mode `n`, <sd> overlaps with <sdn>, <sdl>:
  - <sd>: Delete surrounding
  - <sdn>: Delete next surrounding
  - <sdl>: Delete previous surrounding
- WARNING In mode `n`, <sF> overlaps with <sFn>, <sFl>:
  - <sF>: Find left surrounding
  - <sFn>: Find next left surrounding
  - <sFl>: Find previous left surrounding
- WARNING In mode `n`, <sh> overlaps with <shn>, <shl>:
  - <sh>: Highlight surrounding
  - <shn>: Highlight next surrounding
  - <shl>: Highlight previous surrounding
- WARNING In mode `n`, <sf> overlaps with <sfn>, <sfl>:
  - <sf>: Find right surrounding
  - <sfn>: Find next right surrounding
  - <sfl>: Find previous right surrounding
- WARNING In mode `n`, <sr> overlaps with <srn>, <srl>:
  - <sr>: Replace surrounding
  - <srn>: Replace next surrounding
  - <srl>: Replace previous surrounding
- 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.3.0
on_key: <Space>
State(start): { "Mode(n)", "Node(<Space>)", { keys = "<Space>", update = true, waited = 0 } }
  getchar
  on_key: f
  got: f
  reattach: { "<Space>f", "n" }
  detach: <Space>
  feedkeys: { "Mode(n)", "<Space>f" }
on_key: <Space>f
ModeChanged(n:i)
not safe
attach: { "<Space>", "n" }
on_key: i
on_key: n
on_key: i
on_key: t
on_key: l
on_key: u
on_key: a
on_key: <CR>
ModeChanged(i:n)
not safe
on_key: <CR>
on_key: <Space>
State(start): { "Mode(n)", "Node(<Space>)", { keys = "<Space>", update = true, waited = 0 } }
  getchar
  on_key: f
  got: f
  reattach: { "<Space>f", "n" }
  detach: <Space>
  feedkeys: { "Mode(n)", "<Space>f" }
on_key: <Space>f
ModeChanged(n:i)
not safe
attach: { "<Space>", "n" }
on_key: <C-R>
State(start): { "Mode(i)", "Node(<C-R>)", { keys = "<C-R>", update = true, waited = 0 } }
  getchar
  on_key: <Esc>
  got: <Esc>
on_key: <Esc>
ModeChanged(i:n)
on_key: <Esc>
on_key: <Space>
State(start): { "Mode(n)", "Node(<Space>)", { keys = "<Space>", update = true, waited = 0 } }
  getchar
  on_key: f
  got: f
  reattach: { "<Space>f", "n" }
  detach: <Space>
  feedkeys: { "Mode(n)", "<Space>f" }
on_key: <Space>f
ModeChanged(n:i)
not safe
attach: { "<Space>", "n" }
on_key: i
on_key: n
on_key: i
on_key: t
on_key: l
on_key: u
on_key: a
on_key: <C-R>
State(start): { "Mode(i)", "Node(<C-R>)", { keys = "<C-R>", update = true, waited = 0 } }
  getchar
  on_key: <Esc>
  got: <Esc>
on_key: <Esc>
ModeChanged(i:n)
on_key: <Esc>
on_key: :
ModeChanged(n:c)
on_key: q
on_key: a
on_key: <CR>
ModeChanged(c:n)

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
    { "nvim-telescope/telescope.nvim", opts = {} },
  },
})

[yavorski]

Adding screenshot

[dpetka2001]

@folke I'm hijacking this, since my problem is related, but when in insert mode and press <c-r> which-key menu doesn't pop up for the registers. When in command line pressing <c-r> correctly brings up the which-key menu for registers.

PS: related log with debug = true

Debug Started for v3.4.0
on_key: s
BufReadPost
BufEnter
on_key: i
ModeChanged(n:i)
not safe
on_key: <C-R>
on_key: <Esc>
on_key: <Esc>
ModeChanged(i:n)
on_key: :
ModeChanged(n:c)
on_key: <C-R>
State(start): { "Mode(c)", "Node(<C-R>)", { keys = "<C-R>", update = true, waited = 0 } }
  continue: { "<C-R>", "Mode(c)" }
  getchar
  on_key: <Esc>
  got: <Esc>
on_key: <Esc>
ModeChanged(c:n)
not safe
on_key: :
ModeChanged(n:c)
on_key: q
on_key: <CR>
ModeChanged(c:n)
not safe

[folke]

@dpetka2001 I check this can't reproduce this with a minimal repro. Are you 100% you're up to date?

[yavorski]

I am with latest, it does not open for me too.

[folke]

@yavorski ok, so in a new empty file?
What if you open a file and try then?

[dpetka2001]

@folke Yes, I'm up to date on latest which-key. But I just tried with a fresh LazyVim default installation and the issue does not occur. It works correctly there. Will try to find out what's wrong on my end.

[folke]

Be aware, that you need to have at least one register with a value in order for it to show.

[folke]

Currently wk would not attach to new buffers created with :enew, so without a filename, since BufRead doesn't trigger then.

Added an extra trigger on BufNew.

[yavorski]

Actually just tried with a clean repro it is showing a warning and after that it is poping up, but it is not working with my own config a bit sad : ) ...

[yavorski]

Currently wk would not attach to new buffers created with :enew, so without a filename, since BufRead doesn't trigger then.

Yes it is working with one register!

[dpetka2001]

Still doesn't work on my end. Here's a screencast of LazyVim default installation without any extra configuration

Screencast.2024-07-15.21.26.06.webm

[folke]

Can you reproduce it with the repro template?

[dpetka2001]

No, with the minimal repro it works correctly.

PS: Just to make sure, you mean this one, right?

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
  },
})

[folke]

Can you list the exact steps that lead to the issue?

• open lazyvim
• press ....

[folke]

ok, can reproduce.
It's after restoring a session. That breaks it somehow. Will check

[dpetka2001]

Yes, I almost always use restore session in my workflow.

[dpetka2001]

But in the screencast I showed, I didn't restore session. I just used f from dashboard to open the init.lua file. So, maybe something with the dashboard in general?

[folke]

I added some extra debugging and it seems that when entering insert mode, there's always a <80> char pending for some reason.

Safe(false):pending "<80>"

Just pushed a fix that always ensures the mode is ready regardless of pending chars (which was causing the issue in this case)

Let me know if you'd still experience this issue.

[dpetka2001]

@folke With latest update it works correctly now. Thank you very much!!