folke / which-key.nvim

💥 Create key bindings that stick. WhichKey helps you remember your Neovim keymaps, by showing available keybindings in a popup as you type.
Apache License 2.0
5.12k stars 163 forks source link

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

Closed yavorski closed 1 month ago

yavorski commented 1 month ago

Did you check docs and existing issues?

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 commented 1 month ago

Adding screenshot

image

dpetka2001 commented 1 month ago

@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 commented 1 month ago

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

yavorski commented 1 month ago

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

image

folke commented 1 month ago

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

dpetka2001 commented 1 month ago

@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 commented 1 month ago

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

folke commented 1 month ago

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 commented 1 month ago

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 : ) ...

image

yavorski commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

Can you reproduce it with the repro template?

dpetka2001 commented 1 month ago

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 commented 1 month ago

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

folke commented 1 month ago

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

dpetka2001 commented 1 month ago

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

dpetka2001 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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