fix(state): defer buffer mappings loading to fix localleader menu#942
fix(state): defer buffer mappings loading to fix localleader menu#942niba wants to merge 1 commit intofolke:mainfrom
Conversation
|
This PR is stale because it has been open 30 days with no activity. |
github-actions
bot
added
the
stale
bad bot |
github-actions
bot
removed
the
stale
|
This PR is stale because it has been open 30 days with no activity. |
github-actions
bot
added
the
stale
|
bump |
github-actions
bot
removed
the
stale
|
This PR is stale because it has been open 30 days with no activity. |
bad bot |
github-actions
bot
removed
the
stale
|
This PR is stale because it has been open 30 days with no activity. |
|
ping |
github-actions
bot
removed
the
stale
|
This PR is stale because it has been open 30 days with no activity. |
|
bump |
|
@folke I'm sorry for pinging, but do you mind looking at this PR? |
github-actions
bot
removed
the
stale
|
This PR is stale because it has been open 30 days with no activity. |
|
this is getting tiring |
github-actions
bot
removed
the
stale
|
This PR is stale because it has been open 30 days with no activity. |
|
bump |
github-actions
bot
removed
the
stale
niba
force-pushed
the
fix/localleader_popup
branch
from
d82109f to
71d43fe
Compare
|
If anyone wants to use this version, you can add the following to your config: {
"folke/which-key.nvim",
url = "https://github.com/niba/which-key.nvim",
branch = "fix/localleader_popup",
} |
Works for me. Waiting for the merge 👀 |
Race condition: grug-far creates the buffer and displays it (triggering BufEnter) before calling setupBuffer() which sets the \r, \s, etc. keymaps. By that time which-key has already scanned and cached an empty tree for the \ prefix, so pressing localleader never shows the popup. This is a known which-key bug affecting any plugin that sets buffer-local <localleader> keymaps after the buffer is displayed: - folke/which-key.nvim#1029 (grug-far specific) - folke/which-key.nvim#942 (attempted upstream fix) - folke/which-key.nvim#476 - folke/which-key.nvim#150 Fix by adding a plugin config override for grug-far that registers a FileType autocmd to defer clearing the which-key cache, allowing it to rescan after keymaps are in place. The autocmd is only created when grug-far loads. Prompts: > When using grug in neovim, I find the local leader doesn't work. E.g. I > add sth to the search and to the replace box, then type \ for local leader, > and no keymap comes up. But if I do g? for help first, it starts working. > Debug with tmux > Search online if other people hit the same issue with grug / lazyvim > Update the commit message to include the links to the issues and PRs. > Could the autocmd be defined so it only gets setup when the grug plugin > gets loaded?
|
I hope this can be merged at some point. Until then @felixge's workaround in felixge/dotfiles@eaa1492 is a little less intrusive then using the branch :) |
IMO it's fine using fork (you can just fork it yourself if you have any concerns) the plugin didn't have new commits which change anything for over 6 months It would become tedious to edit the config every time you add new plugin with localleader mappings or if you decide to remap them yourself. |
5 participants
Description
The
which-keymenu fails to appear forlocalleadermappings in newly created buffers. Currently, the only way to make it work is to trigger the standardleadermenu first, which seems to force a state update.It appears that
which-keyattempts to load buffer mappings before the localleadermappings are fully registered. Triggering theleadermenu resolves this because it re-reads the mappings, at which point they are available.This PR defers the reading of the buffer state. This ensures that all mappings are fully established before
which-keyattempts to index them, effectively resolving the race condition.Related Issue(s)
<localleader>mappings #476 (still exists)