You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently where-is cannot see inside transients, so it can for example only tell users that b is bound to magit-branch, but not that magit-checkout is on b b.
Critical bits of where-is (i.e. where-is-internal) are implemented in C, so this will require changes to Emacs, but since we plan to add transient to the core anyway, this probably won't be much of a problem. I might need some help though.
I haven't looked at it in to much detail yet (or rather it has been a while, and I didn't take notes), but this is one way I could imagine this to work.
Look for the requested command as usual. If at least one non-menu binding is found, then show all the found bindings as usual and be done with it. (This is mostly for performance, maybe we should skip the early exit and always do the following as well.)
Otherwise compile a list of found transient prefix commands.
For each transient request a keymap with the suffix commands.
This keymap would not necessarily be identical to the keymap that would be used if the transient actually were invoked and it would be cached. A potential difference is that a transient may feature different suffixes depending on state, e.g., "initiate a rebase" vs. "continue the rebase that is already in progress". I think that is okay. Each transient should be able to control how this tentative keymap is calculated, so this should be done using a generic function. If it really mattered, then a method could refuse to cache.
which-key receives the keymap and handles it like any other sub-keymap.
I believe to remember that where-is already behaves similar to that for menu bindings, calculating them on demand and then caching the result.
The text was updated successfully, but these errors were encountered:
Currently
where-is
cannot see inside transients, so it can for example only tell users thatb
is bound tomagit-branch
, but not thatmagit-checkout
is onb b
.Critical bits of
where-is
(i.e.where-is-internal
) are implemented in C, so this will require changes to Emacs, but since we plan to addtransient
to the core anyway, this probably won't be much of a problem. I might need some help though.I haven't looked at it in to much detail yet (or rather it has been a while, and I didn't take notes), but this is one way I could imagine this to work.
Look for the requested command as usual. If at least one non-menu binding is found, then show all the found bindings as usual and be done with it. (This is mostly for performance, maybe we should skip the early exit and always do the following as well.)
Otherwise compile a list of found transient prefix commands.
For each transient request a keymap with the suffix commands.
This keymap would not necessarily be identical to the keymap that would be used if the transient actually were invoked and it would be cached. A potential difference is that a transient may feature different suffixes depending on state, e.g., "initiate a rebase" vs. "continue the rebase that is already in progress". I think that is okay. Each transient should be able to control how this tentative keymap is calculated, so this should be done using a generic function. If it really mattered, then a method could refuse to cache.
which-key
receives the keymap and handles it like any other sub-keymap.I believe to remember that
where-is
already behaves similar to that for menu bindings, calculating them on demand and then caching the result.The text was updated successfully, but these errors were encountered: