which-key.nvim icon indicating copy to clipboard operation
which-key.nvim copied to clipboard

bug: which-key menu not showing up for `<localleader>` mappings

Open Subjective opened this issue 2 years ago • 7 comments

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)

NVIM v0.10.0-dev-646+gc4df2f08b

Operating system/version

MacOS 13.4

Describe the bug

Hitting the <localleader> key doesn't trigger the which-key menu for buffer local mappings involving the <localleader> key. Interestingly enough, it loads properly after loading the which-key menu for <leader> in the same buffer prior to pressing <localleader>. This is primarily an issue with plugins like spectre, vimtex, diffview, etc. which set keybindings for a specific plugin related filetype.

Btw, this is a duplicate of #172 (sorry), but I noticed that it still seems to be around so I thought I might bring it up again. The workaround suggested in that issue works, but is rather cumbersome:

vim.api.nvim_create_autocmd("FileType", {
  desc = "Set up Spectre Which-Key descriptions",
  group = vim.api.nvim_create_augroup("spectre_mapping_descriptions", { clear = true }),
  pattern = "spectre_panel",
  callback = function()
    vim.keymap.set("n", "<localleader>", function() require("which-key").show "," end, { buffer = true })
  end,
})

Steps To Reproduce

  1. Enter a buffer with buffer local mappings (in the provided config, :Spectre or hit <leader>s
  2. Hit the localleader key
  3. Which-key menu doesn't show up

Expected Behavior

I would expect the which-key menu to display for localleader mappings in a specific buffer.

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)

vim.g.mapleader = " "
vim.g.maplocalleader = ","

-- install plugins
local plugins = {
	"folke/tokyonight.nvim",
	{ "folke/which-key.nvim", opts = {} },
	{
		"nvim-pack/nvim-spectre",
		cmd = "Spectre",
		dependencies = "nvim-lua/plenary.nvim",
		init = function()
			local wk = require "which-key"
		end,
		opts = function()
			local prefix = "<localleader>"

			return {
				open_cmd = "new",
				mapping = {
					send_to_qf = { map = prefix .. "q" },
					replace_cmd = { map = prefix .. "c" },
					show_option_menu = { map = prefix .. "o" },
					run_current_replace = { map = prefix .. "r" },
					run_replace = { map = prefix .. "R" },
					change_view_mode = { map = prefix .. "v" },
					resume_last_search = { map = prefix .. "l" },
				},
			}
		end,
		keys = { { "<leader>s", function() require("spectre").open() end, desc = "Spectre", }, },
	},
}
require("lazy").setup(plugins, {
	root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")

Subjective avatar Jul 09 '23 08:07 Subjective

This approach used to work for me recently. Specifically for fugitive, mapping local leader and getting a menu for that file type. It just stopped working not sure why.

phortonssf avatar Nov 18 '23 06:11 phortonssf

Same for me. I was also using this workaround, but it recently stopped working.

jpasquier avatar Nov 18 '23 08:11 jpasquier

I'm also experiencing this issue. Is there anything we can do to have <localleader> invoke which-key without having to press <leader> first?

januz avatar Dec 10 '23 19:12 januz

Another consequence of this is that the localleader mappings use the default waiting time of timeoutlen. It made me think that the keymaps weren't being mapped, but actually they were, it just that I was being too slow in the key chords. e.g. <localleader>e was executing end-of-word instead.

ericukk avatar Jan 25 '24 15:01 ericukk

This also makes one of the key features of Neorg not work. I frequently jump to the index file with :Neorg index, create a new note with <localleader>nn, and jump back to where I was with :Neorg return. This made it work for me:

-- this is to fix bug: https://github.com/folke/which-key.nvim/issues/476
vim.api.nvim_create_autocmd("FileType", {
  desc = "Set up neorg Which-Key descriptions",
  group = vim.api.nvim_create_augroup("neorg_mapping_descriptions", { clear = true }),
  pattern = "norg",
  callback = function()
    vim.keymap.set("n", "<localleader>", function() require("which-key").show "," end, { buffer = true })
  end,
  })
end,

sailingbonbini avatar Feb 01 '24 11:02 sailingbonbini

This also makes one of the key features of Neorg not work. I frequently jump to the index file with :Neorg index, create a new note with <localleader>nn, and jump back to where I was with :Neorg return. This made it work for me:

-- this is to fix bug: https://github.com/folke/which-key.nvim/issues/476
vim.api.nvim_create_autocmd("FileType", {
  desc = "Set up neorg Which-Key descriptions",
  group = vim.api.nvim_create_augroup("neorg_mapping_descriptions", { clear = true }),
  pattern = "norg",
  callback = function()
    vim.keymap.set("n", "<localleader>", function() require("which-key").show "," end, { buffer = true })
  end,
  })
end,

Your approach worked thank you. I couldn't find anything about the show method in the docs. How did you find out about it? I did make one small adjustment and moved the code to the ftplugin folder vs the autocmd. More of a flavor choice. Cheers!

phortonssf avatar Mar 09 '24 07:03 phortonssf

having the same issue, but not just on specific plugins. I have a lot of buffer specific keymaps using <localleader>, and hitting localleader doesn't trigger "which-key" for me either.

edit: Managed to get the above workaround working for my use case

tgallacher avatar Apr 04 '24 16:04 tgallacher

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.

github-actions[bot] avatar Jul 06 '24 01:07 github-actions[bot]