Kitty keyboard: AltGr (ISO Level 3 Shift) and RCtrl (Compose) keys don't work about wezterm HOT 4 OPEN

Try intl. with AltGr dead keys ...

from wezterm.

That's exactly what the altgr-intl variant is. It's listed as "intl. with AltGr dead keys".

from wezterm.

Hi, I can replicate this.

wezterm version: 20240325_093507_e5ac32f2 x86_64-unknown-linux-gnu
Window Environment: X11 KWin (fedora 39)

I tried the OP's layout, ALTGR+letter combos work fine on all keys with, or without enable_kitty_keyboard.
Same thing with RCTRL used as a compose key.
But, adding SHIFT to a letter with those two modifiers makes no difference, it is ignored, only with enable_kitty_keyboard. Only some letters though.

For instance, ALTGR+y and RCTRL " y produce correctly ü, but ALTGR+SHIFT+y and RCTRL " SHIFT+y do not create the corresponding uppercase letter.

Notice that SHIFT is correctly recognized to produce " instead of ' in the second keycombo.

It works perfectly for other letter pairs, for instance: ß / §, ð / Ð.
Still, the vast majority of shifted level_3 characters are not recognized.

OP's problem seems worse since not even normal ALTGR+letter combos seem to work, but they said that the way it breaks has been inconsistent over time, so I don't know what to make of it, maybe it's just the erratic nature of the same bug.

I tried the same steps with my own layout and it behaves like I just described.

I tried it on bash and on kakoune with wezterm, and on nvim with kitty and I got no issues.

If it can help with debugging, I can make a table with all the keys working / not working.

Regards

from wezterm.

I tried compose-key just now (rctrl).
Exact same thing. Works completely fine without enable_kitty_keyboard, completely ceases to work at all when enabled.

Have also updated to the latest wezterm-nightly before trying the above.

It seems like the terminal doesn't send any bytes at all in my case. (tested with echo -en '\x1b[>1u'; showkey -a; echo -en '\x1b[<u')

from wezterm.