Strange reaction on "menu" button

[korjavin]

I have layout switcher on "menu" button grp:menu_toggle

When I start vim in kitty and press "menu" it makes something wierd.

It changes the capitalization of the next few words.

[kovidgoyal]

You r menu button is being reported as some key press to kitty. Use --debug-keyboard to see what.

[korjavin]

Press xkb_keycode: 0x87 clean_sym: ISO_Next_Group composed_sym: ISO_Next_Group mods: numlock glfw_fallback_key: 348 (MENU) xkb_key: 65383 (Menu)
on_key_input: glfw key: 348 native_code: 0xff67 action: PRESS mods: 0x0 text: '' state: 0 sent key to child
Release xkb_keycode: 0x87 clean_sym: ISO_Next_Group mods: numlock glfw_fallback_key: 348 (MENU) xkb_key: 65383 (Menu)
on_key_input: glfw key: 348 native_code: 0xff67 action: RELEASE mods: 0x0 text: '' state: 0 ignoring as keyboard mode does not allow release events

[kovidgoyal]

According to that the menu key is being correctly dispatched, encoded as
^[[29~ as expected. if vim is not handling the key correctly, its a bug
in vim. You can workaround it by mapping the key press to send something
else using send_text in kitty.conf

[korjavin]

I don't have any problem with vim and this key with lxterminal and gnome-terminal.

[kovidgoyal]

Presumably because lxterminal and gnome-terminal dont support this key.

[trygveaa]

Kitty should probably not interpret the menu key when grp:menu_toggle is on? I see that xterm sends the control code when grp:menu_toggle is not on, but ignores it when it's on.

[kovidgoyal]

I have no clue what grp:menu_toggle is but if someone knows of an API in libxkbcommon to query it feel free to submit a patch against xkb_glfw.c

[trygveaa]

It's an XKB option to use the menu key to switch keyboard layout. You can activate it by running:

setxkbmap -option grp:menu_toggle

[kovidgoyal]

I have no clue how to get libxkbcommon to tell kitty that, if you do
patches are welcome.

[trygveaa]

@kovidgoyal: The issue is caused by this code:

kitty/glfw/xkb_glfw.c

Lines 625 to 632 in 8590334

	if (glfw_sym == GLFW_KEY_UNKNOWN && !key_text[0]) {
	int num_default_syms = xkb_state_key_get_syms(sg->default_state, code_for_sym, &default_syms);
	if (num_default_syms > 0) {
	xkb_sym = default_syms[0];
	glfw_sym = glfw_key_for_sym(xkb_sym);
	is_fallback = true;
	}
	}

When the grp:menu_toggle option is on, xkb_sym is XKB_KEY_ISO_Next_Group and glfw_sym is GLFW_KEY_UNKNOWN at the start of this code. Then you load the keysym from default_keymap which doesn't have any options set, so that returns XKB_KEY_Menu. I'm not sure why you fallback to default_keymap, so I'm not sure what the correct fix for this is?

I guess you could check if xkb_sym is XKB_KEY_ISO_Next_Group in that if condition, but there are more keysyms which should be ignored, like XKB_KEY_ISO_Prev_Group and probably others.

[kovidgoyal]

I dont recall exactly but I'd guess it's to fallback if the key is
unknown. It should be safe to check for next group/prev group in the if.

[trygveaa]

I submitted #2527 which does that. Fallbacking to the default layout when a key is unknown seems to me like something which could potentially lead to more issues though, but I probably don't know enough about this.