keyboard protocol: clarification on locked modifiers about kitty HOT 6 CLOSED

IIRC, kitty does not currently follow the spec exactly in that lock keys are only reported when some other modifier is present as well. I think this was done to make it easier for programs that kind of support CSIu to not get confused by the lock keys.

from kitty.

Or maybe I am misremembering, need to check when am at my dev machine.

from kitty.

Checking, I see caps_lock+space reported as expected when the caps_lock is engaged and the space key is pressed.

from kitty.

Thanks for the quick fix/update! I'll update foot accordingly.

from kitty.

Just to clarify this:

The intent is that with even \e[>1u, locked modifiers should be present for any keypress? Meaning if a user has numlock engaged, then the effect is that all keypresses are sent as escapes (since we need an escape to send the numlock mod). Same for capslock - any capslock key would then be sent as an escape sequence.

Do I have that correct?

from kitty.

No, that's precisely the use case I was thinking of when I said kitty doesn't follow the spec precisely. The lock modifiers are not reported for keys that dont already have a CSIu encoding. This is to make this mode useable in programs that still want to mostly use legacy key handling. So having caps lock engaged and pressing a will just send A. But, having caps lock engaged and pressing an function key does report the modifier since the function key is already encoded as an escape code not as a text.

So while technically this kind of violates the promise of this mode to disambiguate all keys (shift+A and caps_lock A are the same), its worth it for backwards compat. Easy to check with printf "\e[>1u"; showkey -a

from kitty.