noctuid/general.el

Hide key in which-key or group keys

Closed this issue · 6 comments

Hi,

I have the following bindings:

(general-define-key
   :states 'normal
   :keymaps 'override
   :prefix "SPC"
   "1" #'winum-select-window-1
   "2" #'winum-select-window-2
   ...
   "9" #'winum-select-window-9
)

When I enter SPC, which-key displays:

  1 -> winum-select-window-1
  ...
  9 -> winum-select-window-9

I would like to change it to have only the following entry:

  1..9 -> select window 1..9

I did:

"" '(:ignore t :which-key ("1..9" . "select window 1..9"))

But I did not find a way to disable/hide which-key for other keybindings or to define a "group" of keys.
Did I miss something or is it not possible for now?

I don't think which-key supports grouping keys together like this into one entry. The use case would be pretty narrow (mainly for 1-9 and possibly for a-z). I'd suggest making an issue on the which-key repo if you want this functionality.

Correct me if I am wrong but it looks like that when a key is defined in general it inserts
an entry in which-key-replacement-alist for this key. If yes, is it not possible to add a way to disable this behavior? For e.g with something like:

;1
"k" '(whatever-function :which-key nil)
;2
"k" '(whatever-function :which-key 'ignore)
;3
"k" '(whatever-function :which-key-ignore)

If you think that it is possible and want to support this feature I can do a PR.

For now, I am doing:

(general-define-key
   :states 'normal
   :keymaps 'override
   :prefix "SPC"
   "1" #'winum-select-window-1
   "2" #'winum-select-window-2
   ...
   "9" #'winum-select-window-9
   "" '(:ignore t :which-key ("1..9" . "select window 1..9"))
)
(push '((nil . "winum-select-window-[1-9]") . t)
        which-key-replacement-alist)

Yes, I will change it so that :which-key nil will actually put a nil entry in which-key-replacement-alist. Currently, it's just the same as not specifying the keyword at all, and some minor refactoring will be required.

Note to self:

  • Now that the builtin extended definitions are handled the same way as user ones, general-define-key should not have any extended keywords in its arglist (but it would be fine to still mention that many extended def keywords can be used globally in the docstring)
  • non-nil defaults for which-key extended definition keywords should be handled in the which-key extend definition implementation not in general-define-key; check if keyword is in plist to allow explicit nulls

Looking at it again, which key uses t as the replacement to ignore it for your example. :which-key t already works for me. I've added explicit documentation and tests for this. Does this address your issue?

Yes you are right it works with t directly. I did not think to test it with it.

I take the advantage of the opportunity to thank you for your great work on general.el.