Distringuishing between tab key and i key in leader key map?

[okamsn]

Currently, the binding for imenu (M-g i, M-g M-i) is overridden by the binding for move-to-column (M-g TAB).

I have undone the binding on M-g TAB and moved it to M-g <tab>. This stops the keypad state from interpreting the SPC m g i as M-g TAB (M-g C-i). However, it looks like the keypad state cannot find the binding for <tab>. When I press SPC m g <tab>, it is translated to M-g TAB, which is no longer bound.

Is there a way to have they keypad state use the binding for <tab> when there is no binding for TAB?

[DogLooksGood]

My understanding is that <tab> will be translated to TAB unless you have something on ?-<tab>/<tab>. However even if we have something bound to ?-<tab>/<tab>, we can't trigger it in KEYPAD.

Unless we implement something to do low level key translation, that will be KEYPAD 2.0.

[okamsn]

OK. Thank you for the explanation.

In that case, is it possible to separate tab and C-i in the keypad translation? Or, is it possible to assume the Meta modifier instead of the Control modifier for some keymaps?

[DogLooksGood]

I think the best practice here is to not use C-i at all, if you want the bindings work in both GUI and TUI. The same applies to C-m(which is translated to RET) and C-g. You can see why we choose m and g for KEYPAD.

And you can't assume different modifiers for different keymap. How about use C-c <letter> for all user key bindings?

[okamsn]

To make SPC m g i use imenu, what worked for me is

(keymap-unset goto-map "TAB")
(keymap-set goto-map "<tab>" #'move-to-column)
(keymap-set goto-map "C-TAB" #'move-to-column)

However, the pop-up for keybindings (both Which Key mode and Meow's built-in method) still shows that SPC m g i would run move-to-column, even though it now runs imenu. Do you want a new issue for that?