bug: with OSC-52 enabled, which-key doesn't work correctly with registers

[nikfp]

Did you check docs and existing issues?

• [X] I have read all the which-key.nvim docs
• [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)

v0.10.0-dev-2109+gda541c0af

Operating system/version

MacOS and Ubuntu 20/WSL

Describe the bug

When using which-key together with OSC-52 as the docs describe the setup, using " to access registers has a delay and then shows a message that it's waiting for an OSC-52 code. Disabling Which-key fixes the issue.

Steps To Reproduce

1. Clone or copy MRP config repo here
2. Open nvim using config, either in standard config path or using $NVIM_APPNAME
3. Allow Lazy to install as normal, then restart nvim
4. Hit " as you would expect to access registers.

Expected Behavior

Registers should work as expected, using Which-Key pop-up when appropriate.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/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", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  { "folke/which-key.nvim", config = true },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.g.clipboard = {
    name = 'OSC 52',
    copy = {
      ['+'] = require('vim.ui.clipboard.osc52').copy('+'),
      -- ['*'] = require('vim.ui.clipboard.osc52').copy('*'),
    },
    paste = {
      ['+'] = require('vim.ui.clipboard.osc52').paste('+'),
      -- ['*'] = require('vim.ui.clipboard.osc52').paste('*'),
    },
  }

local wk = require("which-key")
wk.register({
  c = { name = "Changing things" },
  d = { name = "Diagnostics" },
  f = { name = "Finding things" },
  g = { name = "Going places" },
  h = { name = "Harpoon" },
  m = { name = "Meta-functions" },
  q = { name = "Quickfix" },
  r = { name = "Run things" },
  s = { name = "Controls splits" },
  u = {
    name = "Utilities",
  },
  w = { name = "Workspace" },
}, { prefix = "<leader>" })

wk.setup()

vim.cmd.colorscheme("tokyonight")
-- add anything else here

[tgbrooks]

FYI I have a work-around for this at this bug which I incorrectly filed with neovim itself.

[folke]

@tgbrooks would be great if you could create a PR with the work-around!

[imroc]

I already used that workaround for several months, cuz I use nvim-0.10 nightly build before, and use neovim+LazyVim in remote dev machine of my daily work.

Share my config (~/.config/nvim/lua/config/options.lua):

if vim.env.SSH_TTY then
  local function paste()
    return { vim.fn.split(vim.fn.getreg(""), "\n"), vim.fn.getregtype("") }
  end
  local osc52 = require("vim.ui.clipboard.osc52")
  vim.g.clipboard = {
    name = "OSC 52",
    copy = {
      ["+"] = osc52.copy("+"),
      ["*"] = osc52.copy("*"),
    },
    paste = {
      ["+"] = paste,
      ["*"] = paste,
    },
  }
end

[tgbrooks]

@folke The work-around isn't fit for a PR unfortunately. It just completely disables system paste functionality, when really it should be done only in situations where OSC52 paste functionality is not present but Neovim is trying to use it anyway. I don't know how to detect that so it just has to be done manually for anyone affected. Presumably, if it were easy to detect then neovim itself wouldn't have to have a timeout in this situation.

[nikfp]

@tgbrooks your workaround did the trick, with one caveat. I'm able to use Which-Key with everything except registers now. Not a deal breaker, :reg is easy enough on the infrequent occasion that I need it. I'm also using tmux.nvim and when I remove that, I get my registers back with Which-Key, but lose yank to clipboard ability. I need to do some more digging.

@folke I can't tell if the problem lies within WK at the moment, there are too many things outside of it that are causing strange behavior, and this all started when I tried to get OSC-52 working which is proving to be it's own bundle of fun. When I have some time to dig deeper I'll report back. Thanks for WK and all your other great plugins, definitely wouldn't be where I am without them.

[folke]

It seems to yield the same result with :reg

[zevelix]

Yeah I think it's just an issue with Neovim and terminals that don't support querying the clipboard with OSC 52. I experienced it with both WezTerm and Windows Terminal launching Neovim with nvim --clean (though I had to make a minimal config to force OSC 52 on Windows Terminal) and running :reg. Maybe there could just be an option to omit "+" & "*" from the list of registers that which-key calls getreg() on in registers.lua if the user's clipboard provider is OSC 52 and they're experiencing timeouts?

[nikfp]

Maybe there could just be an option to omit "+" & "*" from the list of registers that which-key calls getreg() on in registers.lua if the user's clipboard provider is OSC 52 and they're experiencing timeouts?

@folke this is a thought that might actually work, as long as it's documented as an option in the readme. Thoughts?

[folke]

Yes, sure. Feel free to provide a PR. Doesn't even need to be an option. When OSC52 is detected, replace the regs in the view with a message saying so.

[nikfp]

I'll see what I can come up with. Assuming I can understand what you wrote. Your code is the most advanced Lua I've ever read. Truly art if I'm honest.

[folke]

That code was still from when I just started with lua, so it's really not all that clean :)

[zevelix]

Yes, sure. Feel free to provide a PR. Doesn't even need to be an option.

When OSC52 is detected, replace the regs in the view with a message saying so.

I had mentioned it being an option because some terminals do support OSC 52 paste, whether it's by default or opt in, and I wasn't sure if you'd want to alter expected functionality for the (probably small) group of users that have it enabled.

Thanks for all the great Neovim stuff! 👍

[nikfp]

I see a path to fixing this, hacking on it locally now and hopefully I can have a PR over today still.