fix(state): defer buffer mappings loading to fix localleader menu#942

Open

niba wants to merge 1 commit into

niba:fix/localleader_popup

niba commented Jan 26, 2025 •

edited

Loading

Description

The ⁠which-key menu fails to appear for ⁠localleader mappings in newly created buffers. Currently, the only way to make it work is to trigger the standard ⁠leader menu first, which seems to force a state update.

It appears that ⁠which-key attempts to load buffer mappings before the ⁠localleader mappings are fully registered. Triggering the ⁠leader menu 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-key attempts to index them, effectively resolving the race condition.

Related Issue(s)

Fixes bug: which-key menu not showing up for <localleader> mappings #476 (still exists)

niba mentioned this pull request

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

Closed

3 tasks

github-actions Bot commented Feb 27, 2025

Contributor

This PR is stale because it has been open 30 days with no activity.

github-actions Bot added the stale label

disrupted commented Feb 27, 2025

This PR is stale because it has been open 30 days with no activity.

bad bot

github-actions Bot removed the stale label

github-actions Bot commented Mar 30, 2025

Contributor

This PR is stale because it has been open 30 days with no activity.

github-actions Bot added the stale label

RayJameson commented Mar 30, 2025

bump

github-actions Bot removed the stale label

github-actions Bot commented May 1, 2025

Contributor

This PR is stale because it has been open 30 days with no activity.

github-actions Bot added the stale label

disrupted commented May 1, 2025

This PR is stale because it has been open 30 days with no activity.

bad bot

github-actions Bot removed the stale label

github-actions Bot commented Jun 1, 2025

Contributor

This PR is stale because it has been open 30 days with no activity.

github-actions Bot added the stale label

niba commented Jun 1, 2025

Author

ping

github-actions Bot removed the stale label

github-actions Bot commented Jul 3, 2025

Contributor

This PR is stale because it has been open 30 days with no activity.

github-actions Bot added the stale label

niba commented Jul 3, 2025

Author

bump

RayJameson commented Jul 3, 2025

@folke I'm sorry for pinging, but do you mind looking at this PR?

github-actions Bot removed the stale label

github-actions Bot commented Aug 3, 2025

Contributor

This PR is stale because it has been open 30 days with no activity.

github-actions Bot added the stale label

disrupted commented Aug 4, 2025

this is getting tiring

github-actions Bot removed the stale label

RayJameson mentioned this pull request

fix(state): defer loading buffer mappings RayJameson/which-key.nvim#1

Merged

RayJameson added a commit to RayJameson/dotfiles that referenced this pull request


          fix(nvim,which-key): use fork, until local leader fix is merged upstream

folke/which-key.nvim#942

github-actions Bot commented Sep 5, 2025

Contributor

This PR is stale because it has been open 30 days with no activity.

github-actions Bot added the stale label

niba commented Sep 5, 2025

Author

bump

github-actions Bot removed the stale label

ivangeorgiew mentioned this pull request

feat(global): show operator (like gc) and submaps (like gcc) together #1015

Closed

frabul mentioned this pull request

bug: which-key is not triggered by localleader \ in grug-far window #1029

Closed

4 tasks


          fix(state): defer loading buffer mappings

71d43fe

niba force-pushed the fix/localleader_popup branch from d82109f to 71d43fe Compare

December 11, 2025 21:06

github-actions Bot added the size/s label

niba commented Dec 11, 2025

Author

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",
 }

MamaTierra commented Dec 23, 2025

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 👀

felixge added a commit to felixge/dotfiles that referenced this pull request


          fix(neovim): resolve which-key not showing grug-far localleader keymaps

eaa1492

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?

Wikiwix commented Mar 31, 2026

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 :)

RayJameson commented Mar 31, 2026

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.

Wikiwix commented Apr 5, 2026

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.

I fully agree. Just a matter of which trade off one prefers (I don't have other plugins having trouble), and this way I keep checking for upstream updates of which-key automatically.

Perhaps we get this merged at some point :) 🤞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/s