which-key-replacement-alist does not work in combination with which-key-add-keymap-based-replacements

[minad]

which-key still shows "RET +encoding" for the following configuration:

(add-to-list 'which-key-replacement-alist '(("RET") . ("⏎")))
(which-key-add-keymap-based-replacements ctl-x-map
  "RET" "encoding"
  ...)

[justbur]

The keymap based replacement takes precedence over any in which-key-replacement-alist

[minad]

Would it make sense to apply the which-key-replacement-alist regexps afterwards?

[justbur]

I don't think so. I introduced the keymap based replacements to avoid the overhead of processing the replacements alist (#261). Having which-key process the alist after the keymap based replacement would defeat that purpose. It is possible to have multiple entries in the replacement alist apply, but only if there is no keymap-based replacement that supersedes.

[minad]

I don't see the point. If the regexp-based replacement alist is short enough it does not matter if it is applied always. Most of the simple replacements can be done via the keymap (keeping the regexp alist short this way) and the more complex replacements could still be done via regexps. In particular the variable which-key-allow-multiple-replacements could be respected and enable the more expensive behavior only in that case?

[minad]

If you want to keep this behavior as is, is it possible to replace both key and command?

Somehow like this:

(which-key-add-keymap-based-replacements ctl-x-map
  "RET" '("⏎" . "encoding")
  ...)

Edit: Maybe in that case it is simpler to just use the key based replacement without adding "RET" to the keymap based list. This works for me right now:

(which-key-add-key-based-replacements
  "C-x RET" "encoding")

[justbur]

I don't see the point. If the regexp-based replacement alist is short enough it does not matter if it is applied always. Most of the simple replacements can be done via the keymap (keeping the regexp alist short this way) and the more complex replacements could still be done via regexps. In particular the variable which-key-allow-multiple-replacements could be respected and enable the more expensive behavior only in that case?

The point is that the alist for some people (using doom, spacemacs and such) was getting quite long. Of course, if I can guarantee that it's short, then it shouldn't be an issue to use that on top of the keymap replacements. However, if your alist is short anyway, there's really nothing to lose by ignoring the keymap based ones altogether and just using the alist. The alist offers a superset of functionality compared to the keymaps.

If you want to keep this behavior as is, is it possible to replace both key and command?

I could do that. The syntax you proposed is already taken, so I'd either have to break that or come up with something else.

[minad]

I am thinking about another solution for the issue:

• Always apply first the keymap and then the regexp based lookup.
• Count the number of iteration steps regarding regexp replacements. If these exceed some customizable limit print a warning/suggestion, that there are too many regexp replacements and maybe keymaps should be used instead.
• If multiple replacements are activated this could still work, e.g., applying a regexp twice counts it twice.

If something like that would work one could also consider somehow unifying the replacement api, such that "simple" replacements always go to the keymap and regexps go to the regexp list.

But for me things work now nicely. Thank you for your help! which-key is an incredibly useful package! Discoverability features are so important!

[justbur]

The current design can definitely be improved. The keymap replacements were added later and are much cleaner and faster under the surface, so I'd like to have people use those as much as possible. I like the idea of only using the other mechanism for regexp stuff and keeping that very limited but allowing for both together at some point.