Reporting window size events in stdin

[ShrykeWindgrace]

Windows Terminal version

1.16.10261.0

Windows build number

10.0.19044.0 (21H2)

Other Software

Steps to reproduce

I am setting my input handle with ENABLE_VIRTUAL_TERMINAL_INPUT | ENABLE_WINDOW_INPUT | ENABLE_MOUSE_INPUT | ENABLE_EXTENDED_FLAGS,

Stdout's mode is left as default (0x7) with requests for focus reporting, mouse button reporting, and disabling mouse_any reporting: \ESC[?1004h\ESC[?1003l\ESC[?1002h.

Then I read from my stdin.

Expected Behavior

Some sort of binary/VT sequence of bytes to represent a window resize event.

Actual Behavior

Keyboard events are present in stdin (in their VT form), as are mouse and focus events. However, I have nothing when I resize the WT window (both via mouse or via fullscreen toggle via F11).

The phrase "User interactions that change the size of the console screen buffer are reported in the console's input buffer" for ENABLE_WINDOW_INPUT on the page https://learn.microsoft.com/en-us/windows/console/high-level-console-modes has lead me to believe that I should get at least something - maybe not a VT escape sequence per se, but something.

Is there anything in my configuration amiss? Is there a gentle \ESC[?10XXh equivalent of "please give me window resize events, too"?

The example in https://learn.microsoft.com/en-us/windows/console/reading-input-buffer-events works fine without additional configuration.

Cheers!

[DHowett]

Hey @ShrykeWindgrace! This is one place where we could seriously do better. Alright, here goes.

Right now, the window size events come in in the form of INPUT_RECORD structures when you use ReadConsoleInputW. Even in VT mode.

We don't have a VT encoding for window size events for one really annoying reason: nobody does! On non-Windows platforms, these things come in via an asynchronous signal SIGWINCH, and are read out of the tty via the TIOCGSZ IOCTL. We don't have either of those things on which to build a good window size notification primitive, so instead it comes in as raw events in the input stream.

So, I can give you these two things:

1. A "template" for how we deal with it, when all we want is a simple application that reads VT and knows when the window changes size. class ConsoleInputReader sort-of encapsulates all of that annoying stuff and turns your input stream into (1) a buffer of raw VT and (2) callbacks for window size events.
2. A link to WINDOW_BUFFER_SIZE_EVENT generated during window scrolling #281, one of our oldest open issues, which tracks (despite the name) teasing apart how and where and when we generate window input events.

I briefly had a prototype (branch on this repo that mentions l9 and hax) for how the console host could deliver asynchronous signals to client applications for things like this, but it felt too dangerous x low-priority to invest in.

Hope that helps! I'm gonna mark this issue up as a question with resolution=answered and later convert it to discussion. Please feel free to come back with any followups!

[ShrykeWindgrace]

Thanks a lot for the comprehensive answer! I'll see what I can do with this info =)

[determin1st]

Nah, it doesnt work for vertical resize, the Y number is always 9001 for conhost no matter how you resize the window. its not about the window, its about the buffer.

even for X/horizontal, one still must fetch the full info to determine the changes properly.

[determin1st]

was asking fellow terminal user about it, somehow he solved but not answered yet FarGroup/FarManager#829

nix systems have SIGWINCH signal to indicate the change