Closed chrisgrieser closed 1 year ago
Good idea. Just added this.
I really like this feature. I have a sidenote question. How can you make which-key
aware of the new prefix name. Example I currently have in my config
{
"toppair/peek.nvim",
build = "deno task --quiet build:fast",
keys = {
{
"<leader>pp",
function()
local peek = require("peek")
if peek.is_open() then
peek.close()
else
peek.open()
end
end,
desc = "Peek (Markdown Preview)",
ft = "markdown",
},
},
opts = { theme = "dark" },
},
{
"folke/which-key.nvim",
opts = {
defaults = {
["<leader>p"] = { name = "+peek" },
},
},
},
which without the ft = "markdown
it correctly registers the <leader>p
prefix name correctly, but when ft
is present in the keys
section, then which-key
shows when I press <leader>
the following: p -> +prefix
and it doesn't register correctly the which-key
prefix name. Is there any work around to this?
@dpetka2001 that's a bug in which-key. I think there's a PR open to fix that (by reverting another PR). Need to look at it :)
For the moment, as a work around, I added ft = "markdown
for the plugin itself and then added in the init
function the following
init = function()
require("lazyvim.util").on_load("which-key.nvim", function()
require("which-key").register({
["<leader>p"] = { name = "+peek" },
})
end)
end,
which seems to do the trick for the time being, while maintaining the ft
also in the keys
section to only register the key when in Markdown files.
Edit: of course that snippet is Lazyvim specific, in case anyone tries to incorporate it in his own custom config with only lazy.nvim
and which-key
.
@folke Was the which-key
bug ever adressed? I'm still seeing this issue.
As far as I'm aware, it hasn't been addressed yet. But there's a workaround for it in this issue comment until it gets resolved.
Lets put the reference here in case anyone else comes across this: folke/which-key.nvim#514
Did you check the docs?
Is your feature request related to a problem? Please describe.
The
keys
from lazy's plugin spec allows for a very concise definition of keymappings with lazy-loading. However, when it comes to filetype-specific keymaps, there is quite a bit of boilerplate:Describe the solution you'd like
Adding a
ft
key to the Lazy Key Mappings would remove the boilerplate and result in a much cleaner config. It should fit well with lazy's style of configuring things:Describe alternatives you've considered
As a workaround, I basically created my own small utility function. reduces boilerplate a bit, but still not a great solution, I guess.
Additional context
No response