terminal: Terminal: add support for Window Manipulation (CSI t, resize), or reject it explicitly (and force a client resize)
Notes from @j4james:
Note that this is a problem for all the VT resizing sequences too. For example, you’ll get the same problem resizing the screen from within a bash shell like this:
printf "\e[8;10;10t"And if you want to make
modework, then you’ll probably want to start with the VT sequences first, because ultimately that’s how you’re going to have to communicate this information to the Terminal.The real issue, though, is deciding how the Terminal should deal with a resize request. When you’ve got multiple tabs, each potentially requesting a different size, you can’t satisfy all of them at once. I’ve been thinking about this for a while, and there were three approaches that I considered:
Ignore the size request, as we are doing now. But for this to work, it’s vital that the Terminal communicate back to the host that the request has failed. If you don’t do that, the Terminal and conhost get out of sync, and the renderer goes barmy…
Accept the requested size as a kind of virtual window, similar to the way conhost works when the buffer width and window width are different. If the virtual window is larger than the actual window, you’ll need to be able to scroll across the viewport, both horizontally and vertically (the latter being kind of tricky to differentiate from the scrollback).
Accept the requested size and actually resize the whole Terminal window to fit, but only if the tab making the request is currently focused. A background tab shouldn’t be able to change the size. And as with option 1, it’s vital that the resulting sizes are communicated back to the different hosts for each tab.
Personally I’m in favor of option 3, but I suspect others will disagree, and it may need to be a configurable preference. It’s also possible there are other better approaches that I haven’t thought of.
Notes from @egmontkob:
On a more important note, I believe that this escape sequence with a fixed size is borderline problematic/harmful, whereas this one with the “maximized” value, and other nearby escape sequences, are straight harmful (just like when webpages that are allowed to move/resize the browser window – everyone hates that, right?) and terminals should deliberately refuse to implement.
Notes from @DHowett-MSFT: We should choose one of the above options and stick to our guns.
More notes:
- option 4: Only allow a resize like this if there’s a single pane. If there’s two panes, we’ll do the thing from option 1, and ignore it.
- We’re probably gonna just go with option 4
- We’ll add a
compatibility.allowWindowResizingdefaulted totrueto let people fully disable this - If there’s multiple tabs, then inactive tabs won’t notice the current tabs new size till they get focused (and the control is re-added to the UI tree).
- theoretically, one app could ask for 30x80 and another tab 45x120 and switching back and forth would keep resizing the window
- if a inactive tab gets a resize request… then we need to somehow mark that tab asked for a new size, and allow the resize, and resize the
Terminal& buffer, but only resize the window when it gets activated. - This probably needs to be handled as a core->control->app request, so the app can allow/reject
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 38
- Comments: 23 (3 by maintainers)
Commits related to this issue
- Handle resizing Resizing doesn't seem to work well accoring to microsoft/terminal#5094 — committed to darthwalsh/ConsoleInvaders by darthwalsh 3 years ago
The omission of this feature becomes even more critical, because now the users can set Windows Terminal as the default terminal experience. I am supporting an old console app which uses the Win32 API calls SetConsoleScreenBufferSize and SetConsoleWindowInfo. I used to work-around the WT problem using the following algorithm:
However, when WT is set as the default terminal, AllocConsole opens a new instance of WT, so my workaround stops working. Thus, from my point of view, Windows API which have been working for the last 30-ish years break, which is not a good state to be in.
I am personally in favor of option 3, but would like to also propose additional options:
I can’t speak on behalf of the wider organization. Here on the Terminal team, that’s the most straightforward way to measure the community impact of an issue. Obviously, it’s not a hard and fast rule, more of a guideline. Take for example #1571 - that one’s got a PILE of issues dupe’d to it, but hardly any upvotes itself. We still know that’s important based on discussion. But 👍’s are generally easier to show the impact.
I am surprised that after 2 years this is still open without a resolution, but more importantly, no view on the choice to be implemented (1,2 or 3). However I am at best a hobbiest programmer, so I struggled to find a place to fix the code and I am very greatful for the progress made in Terminal over the years and therefore the people who dev this.
So what about workarounds? Is there a way an application can launch and not use the default console as a work around? I use Terminal for everything, but this bug is killing me on 2 apps. Both relating to resizing the window and then commands like clear not working correctly (in Powershell of all things). My alternative would be for those apps to launch into their own personal console that use the old Windows console and performs as desired.?
Has any sort of decision been made on this yet?
For what it’s worth, I’m for option 3.
I find the comparison to web browsers rather unconvincing. Running applications in a terminal is not the same thing as the arbitrary JavaScript code we encounter on the (probably) 100s of unique web pages we casually visit every day. We all sort of get that the web is a bit of a wild west kind of deal, but command line ecosystems are rarely (if ever) that. We generally know what we’re doing when we run things in a terminal.
@2lag I do have users outside, I just put that as part of installation instructions. Had to use big scary “READ THIS, DO THIS FIRST” headers. I don’t know how many people reads them and does do it. There is no way to detect if the script is running inside terminal and throw an error afaik, if there was such a thing this could’ve been better.
This is awesome as far as a workaround for just the local user, but if I’m trying to design something for both Windows 10 and Windows 11 users that is cross compatible, I can’t really expect them to resize the window or change their default settings just to get the full functionality.
I hope sometime soon there can be a solution for this as like you said, it has been 3 years.
It’s been 3 years.
I use batch scripts regularly and my current workaround is to change the “Default terminal application” in Windows Terminal settings to “Windows Console Host”. It’s by default on “Let Windows decide”. This should force all batch scripts at least to start in old console host. Window resizing works.
Ah, thanks for the update. Yes,will click the thumbs up.
@Jibun-no-Kage Nope. We’ll make sure to update this thread when there is. In the meantime, might I recommend the 👍 button to show you’re interested? That’s the best measure we have for which issues are important to the community.