Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reporting window size events in stdin #14958

Closed
ShrykeWindgrace opened this issue Mar 6, 2023 · 2 comments
Closed

Reporting window size events in stdin #14958

ShrykeWindgrace opened this issue Mar 6, 2023 · 2 comments
Assignees
Labels
Issue-Question For questions or discussion Needs-Tag-Fix Doesn't match tag requirements Resolution-Answered Related to questions that have been answered

Comments

@ShrykeWindgrace
Copy link

ShrykeWindgrace commented Mar 6, 2023

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!

@ShrykeWindgrace ShrykeWindgrace added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Mar 6, 2023
@DHowett
Copy link
Member

DHowett commented Mar 9, 2023

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!

@DHowett DHowett closed this as completed Mar 9, 2023
@DHowett DHowett added Issue-Question For questions or discussion Resolution-Answered Related to questions that have been answered and removed Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Mar 9, 2023
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Tag-Fix Doesn't match tag requirements label Mar 9, 2023
@ShrykeWindgrace
Copy link
Author

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

@microsoft microsoft locked and limited conversation to collaborators Mar 9, 2023
@DHowett DHowett converted this issue into discussion #14975 Mar 9, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Issue-Question For questions or discussion Needs-Tag-Fix Doesn't match tag requirements Resolution-Answered Related to questions that have been answered
Projects
None yet
Development

No branches or pull requests

2 participants