VT Extension: In-Band Resize Notifications

[rockorager]

Is your feature request related to a problem? Please describe.
The data stream of every event needed to create terminal applications is within a single stream, except for window resize events.

Describe the solution you'd like
Consider implementing a new VT Extension: Private Mode 2048: In-band resize notifications

Describe alternatives you've considered
SIGWINCH is the only solution. Windows, when using the ReadConsoleInput API delivers window resize events in-band and this API is very nice to use.

Additional context
SIGWINCH is reliable, but can cause race conditions as there is now a third party (the kernel) introduced which delivers the signal from the terminal to the application on it's own schedule, from a different thread than the application is operating on.

Other implementations

• Ghostty has implemented
• Foot has an open PR: https://codeberg.org/dnkl/foot/pulls/1753
• I have integrated this into two TUI libraries I maintain for go and zig
• Wezterm feature request

[kovidgoyal]

You might want to think about extensibility of the reporting escape code
in the future. Have the spec specify that all four fields must be
present always with unknown values set to 0. And specify that subfields
separated by colons may be added in the future, to any field, which must
be ignored by clients that do not understand them.

I can see, for example, adding pixel density information in the future.

[rockorager]

Thanks for the suggestions. I think I had originally thought all fields should be present but went with allowing the last two to be dropped - but requiring all four seems like a better choice. I will update with that, and agree about adding that any field may contain a subparam.

[kovidgoyal]

Oh and in your spec you have the order of the parameters in DECRPM mixed up, the second one is the mode value, the first one is mode number.

[rockorager]

Oh and in your spec you have the order of the parameters in DECRPM mixed up, the second one is the mode value, the first one is mode number.

Fixed!

[kovidgoyal]

One more point, the spec should state that the terminal must reply with the current size when the mode is switched on, even if it was already on.

[kovidgoyal]

And another point, the spec should probably specify sequencing of the events. Terminals must all follow the same sequence:

1. First, do the actual resize of the terminal data structures
2. Send both SIGWNCH and resize events. It is undefined which the client program will receive first.

That is, it is imperative the client receive the resize events only once the terminal has finished resizing its internal data structures/state.

Just FYI I added support for these events to all the kittens in kitty.

[rockorager]

Just FYI I added support for these events to all the kittens in kitty.

Very cool!

Good points regarding sequencing - I will update the spec with that