Implement CSI ? 2048 h (inband resize notification)

[ldemailly]

Description of the new feature

Given that there is no SIGWINCH on windows and using ReadConsoleInput is a pain when doing cross platform TUIs (because the codes are completely different than what you get from stdin)

It would be awesome for windows terminal to implement CSI ? 2048 h

cc @geofpwhite

Proposed technical implementation details

https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3704bd83

[o-sdn-o]

IMO these are all half-measures. A handshake protocol between the terminal and the application(s) is needed.

[ldemailly]

IMO these are all half-measures. A handshake protocol between the terminal and the application(s) is needed.

can you elaborate ? there is already a handshake : send csi instructions, get replies

[o-sdn-o]

can you elaborate ? there is already a handshake : send csi instructions, get replies

I mean something like this:

Mandatory synchronization

When the terminal window is resized, the changes are only applied after a handshake between the terminal and the application. Successive multiple resizing of the window initiates the same number of handshakes.

Handshake steps:

1. Terminal requests a new size, omitting all other parameters.
   • Application receives the request and prepares for resizing, e.g. by updating, cropping or deleting visible lines.
2. Application replies with the same message as the request.
3. Terminal applies the new size and sends the changes.
   • Application updates its UI.

Terminal:    ESC _ event=window ; size=<Width>,<Height> ESC \
Application: ESC _ event=window ; size=<Width>,<Height> ESC \
Terminal:    ESC _ event=window ; size=<Width>,<Height> ; cursor=<X>,<Y> ; region=<Left>,<Top>,<Right>,<Bottom> ; selection=<StartX>,<StartY>,<EndX>,<EndY>,<Mode> ESC \

Note that the terminal window resizing always reflows the scrollback, so the window size, cursor position, scrolling regions, and selection coordinates are subject to change during step 3. Upon receiving the resize request (step 1), a fullscreen application can prepare a scrollback by cropping visible lines to avoid unwanted line wrapping or line extrusion, then send a resize confirmation (step 2). In case the aplication's output is anchored to the current cursor position or uses scrolling regions, the application should wait after step 2 for the updated values before continuing to output.

Hypothetical case with Far Manager (FM):

• FM saves visible original scrollback.
• FM draws its UI on top of the visible original scrollback.
• Terminal sends a resize request.
• FM receives request.
• FM restores the original scrollback.
• FM replies on resize request.
• Terminal receives reply.
• Terminal resizes the window and reflows the scrollback.
• Terminal sends modified window parameters.
• FM receives modified window parameters.
• FM saves the modified scrollback.
• FM draws its UI on top of the scrollback.

[ldemailly]

What you have sounds great but it seems to be... not sure what actually.. a library? a terminal? a protocol proposal?

In any case, not sure what is wrong with the ?2048 semi standard existing proposal ?

[o-sdn-o]

This is an idea, just some thoughts on how it should ideally be.

what is wrong with the ?2048 semi standard existing proposal ?

This solves part of the problem (crossplatformability), but other questions remain.

[o-sdn-o]

I'm not against it, I'm just sharing my thoughts

[j4james]

Just as a point of comparison, DEC had similar functionality on their VAX VT220 emulator. VTEEWR (Enable Window Event Reports) was an OSC sequence which let you request notifications for a number of different events: window resizing, moving, minimizing and restoring, losing and gaining focus. The notifications for those events were also in the form of an OSC sequence.

For example \e]2E;5\e\\ would enable window resizing reports (that's event 5), and an example report would look something like \e]2R;5;1.2;3.4;80;24\e\\. The 5 indicates the event type, 1.2 and 3.4 are the x and y coordinates of the window, and 80 and 24 indicate the width and height (resize events included both the position and size).

[ldemailly]

nice that would work too. @rockorager how come you (someone else?) came up with a different thing then?

[rockorager]

1. I wasn't aware of it
2. Having pixels is very nice, would have needed an extension to add that
3. Private modes are nice because there is an established query mechanism for them

Cool that there was an existing mode for this though!

[DHowett]

You know, I don't hate it. We already have in-band signaling for Windows consumers, so why not? There's some interesting artifacts that will be introduced by our hosting infrastructure, though.

[DHowett]

I'm putting it on the backlog at a not super high priority. :)

[gdamore]

The CSI 2048 mechanism has got some broad acceptance and includes pixel support (needed for sixel graphics, kitty graphics, etc.), and it would be nicer for a number of applications than win32-input-mode extensions (because win32-input-mode is kind of all or nothing proposition - if your application does not properly clean up you can't type anything to fix the terminal, all you can do is close it.)

That said, for my use case, win32-input-mode extensions for this would work perfectly well.