add support for win32-input-mode

[unxed]

kitty's enhanced keyboard protocol is not the only existing enhanced keyboard protocol supported by terminals. There also exist the other one, called win32-input-mode.

Protocol spec: https://github.com/microsoft/terminal/blob/main/doc/specs/%234999%20-%20Improved%20keyboard%20handling%20in%20Conpty.md

Reference implementation on the terminal side: https://github.com/wez/wezterm/issues/1509

Reference implementation on the console app side: https://github.com/elfmz/far2l/pull/1581

Reference implementation on the TUI framework side: https://github.com/magiblot/tvision/commit/5c017a81ef82876a27532a5676e653f035346b49

NB! Windows Terminal's implementation is buggy and needs a special workaround for handling mouse events properly. Reference implementations of such workaround: https://github.com/elfmz/far2l/pull/2085 https://github.com/magiblot/tvision/commit/ae1a6859b48806dcd13d652d451eca28b934a539

[dankamongmen]

interesting, thanks for bringing this to my attention!

[unxed]

Nice to hear that! If so, it's probably worth mentioning some other TUI UX enriching techniques:

1. far2l terminal extensions (reach keyboard support, clipboard, desktop notifications) https://github.com/elfmz/far2l/blob/master/WinPort/FarTTY.h Supported by cyd01's kitty, Turbo Vision, some other apps

2. iTerm2's RAW input mode https://gitlab.com/gnachman/iterm2/-/issues/7440#note_129307021 Supported by far2l (in TTY backend only, not in the internal VT)

3. OSC52 for clipboard access. Supported by far2l, kovidgoyal's kitty (with it's own extensions) and in some other apps https://bugs.kde.org/show_bug.cgi?id=372116 https://sw.kovidgoyal.net/kitty/clipboard/

4. Bracketed paste (as not all terminals supporting OSC52 support it for paste operation, it is often used as alternative). https://github.com/dankamongmen/notcurses/issues/2704

[dankamongmen]

Nice to hear that! If so, it's probably worth mentioning some other TUI UX enriching techniques:

1. far2l terminal extensions (reach keyboard support, clipboard, desktop notifications)

i haven't looked at this yet, but clipboard/desktop etc. seems better handled by the terminal emulator itself? i definitely don't want to go talking to desktop notification APIs, i think.

2. iTerm2's RAW input mode https://gitlab.com/gnachman/iterm2/-/issues/7440#note_129307021 Supported by far2l (in TTY backend only, not in the internal VT)

i'll take a look at this

3. OSC52 for clipboard access. Supported by far2l, kovidgoyal's kitty (with it's own extensions) and in some other apps

same as 1 above

4. Bracketed paste (as not all terminals supporting OSC52 support it for paste operation, it is often used as alternative). support bracketed paste mode #2704

i'd considered this and it too seems to be a TE thing, no?

[unxed]

i haven't looked at this yet, but clipboard/desktop etc. seems better handled by the terminal emulator itself?

OSC52 and far2l extensions are supported in at least one TUI framework: https://github.com/magiblot/tvision/issues/82#issuecomment-1373027084

i'd considered this and it too seems to be a TE thing, no?

TE should support it too, of course. But the app (or is framework) also should. https://en.wikipedia.org/wiki/Bracketed-paste

[dankamongmen]

i'd considered this and it too seems to be a TE thing, no?

TE should support it too, of course. But the app (or is framework) also should. https://en.wikipedia.org/wiki/Bracketed-paste

looking at it, i see what you mean. it's not relevant to me necessarily, but i ought maybe expose it to the app.

[neurocyte]

notcurses already passes escape sequences that it does not implement onwards to the application and I have implemented OSC52 and bracketed paste in my notcurses application with minimal effort even without any help from notcurses.

I'm not sure I see the value of adding clipboard support directly into notcurses itself. What would the API look like and how would it fit into the current input processing model? I assume it would be impossible to implement either clipboard variant without having some sort of (likely unbounded) input buffering inside notcurses. I'm not sure that's a nice way to go.