Within the Comprehensive keyboard handling protocol, what is the functional difference between the 'Report alternate keys' and the 'Report associated text' progressive enhancements?

[tealsnow]

So I'm in the process of creating an application that will take advantage of the 'comprehensive keyboard handling in terminals' protocol extension, and I'm struggling to see the difference between the two progressive enhancements.

For example, with the following progressive enhancements enabled:

• Disambiguate escape codes
• Report alternate keys
• Report all keys as escape codes
• Report associated text

a provides: 97;129;97
shift+a provides: 97:65;130;65
And strangly pressing λ (typed using xcompose) provides: 955::92;129

The first two make sense, although they repeat themselves.
The λ one makes sense to a degree. It does 'report an alternate key' being '\', a perfectly acceptable alternate character.
But it fails to 'report associated text', which is not really an issue as the actual first 'number' is the correct Unicode.
And there are two colons, not sure what's happening there.

So what I'm asking is what the difference is between the 'report alternate keys' and the 'report associated text' progressive enhancements are. And what is happing with the lambda?

Thank you.

[kovidgoyal]

report alternate keys reports the value of the key in the "standard keyboard layout". For example, on a russian keyboard it would report the cyrillic key C as the C and the ascii C. This allows applications to define a shortcut like ctrl+c that works in any keyboard layout. report associated text reports all the text a key press generates as a sequence of unicode numbers as part of the escape code. This is needed because without it there would be no way to have release events for key presses that generate text. Often the unicode number will be the same as the key number or the shifted key number. But sometimes it wont. In particular with IME it can be a whole word or phrase. In your lambda case the text being reported is ĩ why your xcompose rule is generating that text I haven't a clue, use --debug-input to get more info.

[tealsnow]

Thank you for the response.
So if I do not care about the event types would I have any reason to use the associated text?

I think you are mistaken for it reporting ĩ, as 955 in hex is 0x3BB and 92 is 0x5c, apologies if it was unclear I was using decimal.

I'm still confused about the double colon, is this intentional?

Anyway here is the Xcompose rule and --debug-input output if it's of any use.
Thank you again.

Xcompose rule

# GREEK SMALL LETTER LAMBDA
#            .        \
<Multi_key> <period> <backslash>           : "λ"   U03BB

--debug-input output when pressing compose followed by '.' and '\'

Press xkb_keycode: 0x87 clean_sym: Multi_key compose not complete, ignoring.
Release xkb_keycode: 0x87 clean_sym: Multi_key mods: numlock glfw_key: 0 (UNKNOWN) xkb_key: 65312 (Multi_key) alternate_key: 57363 (MENU)
on_key_input: glfw key: 0x0 native_code: 0xff20 action: RELEASE mods: numlock text: '' state: 0 ignoring release event for previous press that was handled as shortcut
Press xkb_keycode: 0x3c clean_sym: period compose not complete, ignoring.
Press xkb_keycode: 0x33 clean_sym: backslash composed_sym: U03BB composed_text: λ mods: numlock glfw_key: 955 (λ) xkb_key: 16778171 (U03BB) shifted_key: 92 (\) alternate_key: 92 (\)
on_key_input: glfw key: 0x3bb native_code: 0x10003bb action: REPEAT mods: numlock text: 'λ' state: 0 sent text to child
Release xkb_keycode: 0x3c clean_sym: period mods: numlock glfw_key: 46 (.) xkb_key: 46 (period)
Release xkb_keycode: 0x33 clean_sym: backslash mods: numlock glfw_key: 92 (\) xkb_key: 92 (backslash)

Although it does not look it, the input was done as such: '. down', '. up', '\ down', '\ up'

[kovidgoyal]

Text is only ever reported with a press event. So not sure what you mean by you dont care about the event types. A double colon means an empty sub-field. Search the spec page for empty. And the unicode text is the last number not the first. The first is the key code. https://sw.kovidgoyal.net/kitty/keyboard-protocol/#text-as-code-points

[tealsnow]

Okay, I now understand the empty case, but is it possible for it to not be empty such as CSI unicode-key-code:alternate-key-code:base-layout-key?

[kovidgoyal]

yes of course. You can have both a shifted key and a base layout key

[tealsnow]

Thank you very much.