In kitty keyboard protocol, should associated text be repertod for non u ending sequences

[kchibisov]

On macOS function keys tend to carry some text, so pressing F2 on macOS generates the 63237 (integer for char it generates, depends on how you obtain it), however the escape for F2 is of a form CSI 1 Q, which is not u ending one.

Should it be reported as CSI 1 ; 63237 Q (only associated text enabled) or should terminal discard the associated text entirely. If so clarification could be needed to tell that associated text can not be present for keys that are not CSI u.

[kovidgoyal]

On Mon, Dec 16, 2024 at 05:36:11PM -0800, Kirill Chibisov wrote: On macOS function keys tend to carry some text, so pressing `F2` on macOS generates the `63237` (integer for char it generates, depends on how you obtain it), however the escape for `F2` is of a form `CSI 1 Q`, which is not `u` ending one.

What keyboard encoding on macOS produces text from function keys? Pressing F1 inside textEdit doesnt for me on US and US International at least.

Should it be reported as `CSI 1 ; 63237 Q` (only associated text enabled) or should terminal discard the associated text entirely. If so clarification could be needed to tell that associated text can not be present for keys that are not `CSI u`.

The trailer only affects the value of the *number* field (the first number of the escape code that encodes the key identity. For non-u trailers the number is always 1. The rest of the escape code is identical in form to the one with u trailer. The only reason for the alternate trailers is for legacy compatibility so that the form of the encoding matches that in the legacy protocol then there are no modifiers, or only the legacy supported modifiers. and no shifted/alternate keys/text.

[tstack]

What keyboard encoding on macOS produces text from function keys?

The keycodes for the function keys in the NSEvent contain the 63237 value. This SO question kinda covers the MacOS part of the plumbing:

https://stackoverflow.com/questions/77088641/f2-key-press-event-on-macos

Alacritty is passing the keycode value along in the kitty keyboard event. I'm trying to get clarity on the behavior here. This is coming up because notcurses is not handling the sequence sent by alacritty.

[kchibisov]

The point is that it's not a scancode, but a characters field on NSEvent, so it maps them to some unicode characters, which we pass through.

[kchibisov]

What keyboard encoding on macOS produces text from function keys?
Pressing F1 inside textEdit doesnt for me on US and US International at
least.

IIRC NSEvent has characters set for function keys, more higher level UI stuff could discard all of that, but the NSEvent does have characters for them. I can not test at the moment to ensure, but I know that our user brought up that we emit strange text along the F1 press for associated text, which I recall is coming from the characters on the NSEvent.

I know that this is more of a true for F21-F24, since they're encoded inside the characters and don't really have scancode that uniquely matches them IIRC, F21-24 carries (0xf718-0xf71b respectively).

[kovidgoyal]

You should not be using NSEvent directly to handle key events in Cocoa, if you do that your keyboard handling will not match platform native applications. IIRC you need to call some combination of UCKeyTranslate and interpretKeyEvents and then reverse engineer what cocoa would do with the key. Yes, Apple's keyboard API's suck. Pressing no function key F1-F12 produces text in any cocoa native application as far as I know in US layout. But anyway, as far as your question about the protocol itself is concerned, there is no restriction on non-u forms of the escape code, other than the one I already mentioned about the first number field being 1.

[kchibisov]

But anyway, as far as your question about the protocol itself is
concerned, there is no restriction on non-u forms of the escape code,
other than the one I already mentioned about the first number field
being 1.

Thanks, so there's no issue in what we're doing then and I've understood it correctly that it's all pretty much the same.

as for macOS handling, we do use both functions you've mentioned, but we don't use it for one field in the key event for whatever reason. maybe it was an oversight or maybe people just hasn't bothered much with it, since it's macOS and mostly all of that is undocumented.