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
4.76k stars 154 forks source link

bug: which-key errors out when pressing wrong key combo in Command Line buffer mode #558

Closed mrs4ndman closed 1 month ago

mrs4ndman commented 6 months ago

Did you check docs and existing issues?

Neovim version (nvim -v)

NVIM v0.10.0-dev-1932+gd9d9d9434

Operating system/version

Pop_OS 22.04 (Linux)

Describe the bug

which-key presents an error → In the Command-line window (opened with q:, you hit the Leader key for completing available keybinds → Hit the wrong key (e or t instead of w as in the example) → Which-key gives an error and doesn't remove it's previous window. Resulting view image

Steps To Reproduce

Steps to reproduce:

  1. Run nvim -u repro.lua with the provided repro.lua

  2. Once inside Neovim, hit q:

  3. Then, while inside the Command Line buffer, hit Space + q (leader + q) instead of the defined Space + w leader + w keybind. Which-key presents this error:

    E5108: Error executing lua ...al/share/nvim/lazy/which-key.nvim/lua/which-key/view.lua:156: E11: Invalid in command-line window; <CR> executes, CTRL-C quits
    stack traceback:
        [C]: in function 'nvim_buf_delete'
        ...al/share/nvim/lazy/which-key.nvim/lua/which-key/view.lua:156: in function 'hide'
    ... 
    ... 
    [string ":lua"]:1: in main chunk
  4. The previous which-key window is still rendered on the bottom part of the screen, and only disappears on Neovim restart.

Expected Behavior

The which-key window should disappear without erroring out

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.cmd.colorscheme("tokyonight")
-- add anything else here

vim.g.mapleader = " "
vim.keymap.set("n", "<leader>w", function()
    print("nope")
end)
d-karl commented 6 months ago

Additional issue description: I hit an issue with using <C-r> to paste into the command line buffer. This will open the current registers in which-key. It would leave me in an undesirable state with the which-key "registers" window open, but immediately throwing an error and the which-key window failing to close afterwards. This would hide the contents of the command line buffer.

Not a fix, but potential workaround is disabling which-key in the "command line" buffer. For this workaround, you may configure which-key to disable in filetype "vim" , which the command buffer is using:

{
    disable = {
        filetypes = { "vim" },
    }
}

See which-key docs

konosubakonoakua commented 4 months ago

Additional issue description: I hit an issue with using <C-r> to paste into the command line buffer. This will open the current registers in which-key. It would leave me in an undesirable state with the which-key "registers" window open, but immediately throwing an error and the which-key window failing to close afterwards. This would hide the contents of the command line buffer.

Not a fix, but potential workaround is disabling which-key in the "command line" buffer. For this workaround, you may configure which-key to disable in filetype "vim" , which the command buffer is using:

{
    disable = {
        filetypes = { "vim" },
    }
}

See which-key docs

setting filetype to vim is not good. maybe we can disable it directly in code.

rickalex21 commented 4 months ago

I am getting the same error, the patch from @konosubakonoakua works here. Ideally there should be a way to disable lua plugins, not sure how to go about it with or without LazyVim?

Option 1

In LazyVim

-- boolean to enable or disable plugin on BufWinEnter?
new_opt = function() return vim.api.nvim_get_mode().mode == "c" end,

Option 2

Create your own lua, this is not the correct way but this is the idea.

local ag_cmdmode = vim.api.nvim_create_augroup('cmdmode', { clear = true })
-- vim.api.nvim_create_autocmd
vim.api.nvim_create_autocmd('CmdLineEnter', {
  group = ag_cmdmode,
  callback = function ()
  require('which-key').setup({new_enabled_cmd = false})
  end
})

vim.api.nvim_create_autocmd('CmdLineLeave', {
  group = ag_cmdmode,
  callback = function ()
  require('which-key').setup({new_enabled_cmd = false})
  end
})
baodrate commented 2 months ago

workaround for disabling which-key in command-line windows, without disabling it for vim filetype (involves monkey-patching which-key):

local view = require("which-key.view")
local is_enabled_orig = view.is_enabled
view.is_enabled = function(bufnr)
    return is_enabled_orig(bufnr) and vim.fn.getcmdwintype() == ""
end