-
Notifications
You must be signed in to change notification settings - Fork 242
fix(state): defer buffer mappings loading to fix localleader menu #942
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
This PR is stale because it has been open 30 days with no activity. |
bad bot |
|
This PR is stale because it has been open 30 days with no activity. |
|
bump |
|
This PR is stale because it has been open 30 days with no activity. |
bad bot |
|
This PR is stale because it has been open 30 days with no activity. |
|
ping |
|
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? |
|
This PR is stale because it has been open 30 days with no activity. |
|
this is getting tiring |
|
This PR is stale because it has been open 30 days with no activity. |
|
bump |
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 👀 |
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)