starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Terminal: add support for Window Manipulation (CSI t, resize), or reject it explicitly (and force a client resize) #7111

New Issue
Open
opened 2026-01-31 00:55:18 +00:00 by claunia · 38 comments
claunia commented 2026-01-31 00:55:18 +00:00
Owner
Copy Link

Originally created by @DHowett-MSFT on GitHub (Mar 24, 2020).

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 mode work, 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:

  1. 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..

  2. 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).

  3. 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.allowWindowResizing defaulted to true to 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
Originally created by @DHowett-MSFT on GitHub (Mar 24, 2020). 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 `mode` work, 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: > > 1. 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.. > > 2. 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). > > 3. 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. <hr> 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.allowWindowResizing` defaulted to `true` to 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
claunia added the Issue-TaskIn-PRArea-VTProduct-TerminalPriority-2 labels 2026-01-31 00:55:19 +00:00
claunia commented 2026-01-31 00:55:20 +00:00
Author
Owner
Copy Link

@jdebp commented on GitHub (Mar 24, 2020):

It's worth noting that the problems don't arise with just 1 tab. With just 1 tab, you can resize the terminal GUI window willy-nilly as the resize events come down the pipe, and behave exactly as the prior console server's GUI windows did in response to size changes. It's what to do when there are 2 or more tabs, each wanting a different terminal size, that is the problem.

Looking to existing practice, Konsole has some noteworthy behaviour. The control sequence resizes the terminal exactly as requested. stty shows the requested number of rows and columns, and text wraps at the designated column. Size changes take effect even if this is not the active tab. The GUI window does not change when the active tab's size is changed, however. Things stay that way until the next time that the tab is switched back to from another tab, at which point the pseudo-terminal receives a resize event sizing it back to the size of the GUI window. If there is only 1 tab present this never happens, as the single tab is never switched away from and never switched back to.

This is of course, to discuss resizing in the GUI front-end. The actual console screen buffer should definitely support resizing via control sequences, just as it supports resizing via SetConsoleScreenBufferSize().

How are you supporting sending along to the GUI front-ends changes made by SetConsoleScreenBufferSize() and SetConsoleWindowInfo(), and changes to the window size made by the GUI front end? You've only provided one set of size information in ResizePseudoConsole(), and appear to be treating that as the console screen buffer size. How are GUI terminal emulator applications to pass the other size through so that console I/O applications can see it?

@jdebp commented on GitHub (Mar 24, 2020): It's worth noting that the problems don't arise with just 1 tab. With just 1 tab, you can resize the terminal GUI window willy-nilly as the resize events come down the pipe, and behave exactly as the prior console server's GUI windows did in response to size changes. It's what to do when there are 2 or more tabs, each wanting a different terminal size, that is the problem. Looking to existing practice, Konsole has some noteworthy behaviour. The control sequence resizes the terminal exactly as requested. `stty` shows the requested number of rows and columns, and text wraps at the designated column. Size changes take effect even if this is not the active tab. The GUI window does not change when the active tab's size is changed, however. Things stay that way _until the next time that the tab is switched back to_ from another tab, at which point the pseudo-terminal receives a resize event sizing it back to the size of the GUI window. If there is only 1 tab present _this never happens_, as the single tab is never switched away from and never switched back to. This is of course, to discuss resizing in the GUI front-end. The actual console screen buffer _should definitely_ support resizing via control sequences, just as it supports resizing via `SetConsoleScreenBufferSize()`. How are you supporting sending along to the GUI front-ends changes made by `SetConsoleScreenBufferSize()` and `SetConsoleWindowInfo()`, and changes to the window size made by the GUI front end? You've only provided one set of size information in `ResizePseudoConsole()`, and appear to be treating that as the console screen buffer size. How are GUI terminal emulator applications to pass the other size through so that console I/O applications can see it?
claunia commented 2026-01-31 00:55:20 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Mar 24, 2020):

Looking to existing practice, Konsole has some noteworthy behaviour.

If I had to make a guess, my guess would be that this behavior is not by design, just whatever happened to come out of the simplest implementation, using the UI libraries used by Konsole.

Let's take a step back. You don't have to support any kind of app-initiated resize. Let's just take a tabbed UI where whatever is inside the tab can query the dimensions at any time, as it's necessarily the case with terminals. There's already a nontrivial question: When should inactive terminals receive the resize event?

Immediately? That might be a waste of CPU time, both from the terminal and from the hosted apps, since you don't squash multiple resize events into one; and a waste of network traffic, if there's ssh involved. Especially if resizing isn't super fast (e.g. in VTE the time required to rewrap is proportional to the number of scrollback lines), doing it for multiple tabs at once might cause a noticeable lag. It also might trigger some apps to exit, if they don't support one of the intermediate (e.g. extremely small) size, or might cause bad display in cases that don't really like getting resized (shell prompts typically play badly with rewrap-on-resize).

Or when that tab is switched to? In that case switching is a weird experience, you don't immediately get to see the desired contents, but you see a resize dance, even including ssh latency if it's involved.

Or some more complex solution in between, e.g. resize when the mouse dragging the window border is released, or after a timeout?)

The same question goes to some other kinds of apps too, e.g. most notably web browsers. Do they resize the page (e.g. responsive layout) immediately, or when that tab is switched to? I wouldn't be surprised if the answer varied across browsers, or even within the same browser varied across OSes (graphical toolkits).

Now combine it with various resizing strategies across terminals (some force a grid, some don't), various tab switching experiences (some prefer to keep the pixel size, some prefer to keep the character size), various zooming experiences (some might zoom all tabs at once, some zoom each tab separately), and then let's even introduce app-initiated resizes. There are loads of possible behaviors to pick from, and it's really hard to tell which one is better.

@egmontkob commented on GitHub (Mar 24, 2020): > Looking to existing practice, Konsole has some noteworthy behaviour. If I had to make a guess, my guess would be that this behavior is not by design, just whatever happened to come out of the simplest implementation, using the UI libraries used by Konsole. Let's take a step back. You don't have to support any kind of app-initiated resize. Let's just take a tabbed UI where whatever is inside the tab can _query_ the dimensions at any time, as it's necessarily the case with terminals. There's already a nontrivial question: When should inactive terminals receive the resize event? Immediately? That might be a waste of CPU time, both from the terminal and from the hosted apps, since you don't squash multiple resize events into one; and a waste of network traffic, if there's ssh involved. Especially if resizing isn't super fast (e.g. in VTE the time required to rewrap is proportional to the number of scrollback lines), doing it for multiple tabs at once might cause a noticeable lag. It also might trigger some apps to exit, if they don't support one of the intermediate (e.g. extremely small) size, or might cause bad display in cases that don't really like getting resized (shell prompts typically play badly with rewrap-on-resize). Or when that tab is switched to? In that case switching is a weird experience, you don't immediately get to see the desired contents, but you see a resize dance, even including ssh latency if it's involved. Or some more complex solution in between, e.g. resize when the mouse dragging the window border is released, or after a timeout?) The same question goes to some other kinds of apps too, e.g. most notably web browsers. Do they resize the page (e.g. responsive layout) immediately, or when that tab is switched to? I wouldn't be surprised if the answer varied across browsers, or even within the same browser varied across OSes (graphical toolkits). Now combine it with various resizing strategies across terminals (some force a grid, some don't), various tab switching experiences (some prefer to keep the pixel size, some prefer to keep the character size), various zooming experiences (some might zoom all tabs at once, some zoom each tab separately), and then let's even introduce app-initiated resizes. There are loads of possible behaviors to pick from, and it's really hard to tell which one is better.
claunia commented 2026-01-31 00:55:21 +00:00
Author
Owner
Copy Link

@SWB54 commented on GitHub (Apr 7, 2020):

Would I be correct to assume that this issue also encompasses non-VT resizing? For example, the .NET API Console.WindowWidth, which I believe maps (on Windows) to the Win32 APIs SetConsoleScreenBufferSize() and SetConsoleWindowInfo().

If so, I am in favor of either option 2 or 3 (some version of honoring the request), but not 1 (ignoring it). I just ran into this issue today. I have a .NET Core console app that prints formatted tables with relatively long rows. If the console width is too narrow to display the table, I increase it via Console.WindowWidth. This works in a cmd.exe window but not (yet) inside Windows Terminal.

@SWB54 commented on GitHub (Apr 7, 2020): Would I be correct to assume that this issue also encompasses non-VT resizing? For example, the .NET API [`Console.WindowWidth`](https://docs.microsoft.com/en-us/dotnet/api/system.console.windowwidth), which I believe maps (on Windows) to the Win32 APIs [`SetConsoleScreenBufferSize()`](https://docs.microsoft.com/en-us/windows/console/setconsolescreenbuffersize) and [`SetConsoleWindowInfo()`](https://docs.microsoft.com/en-us/windows/console/setconsolewindowinfo). If so, I am in favor of either option 2 or 3 (some version of honoring the request), but not 1 (ignoring it). I just ran into this issue today. I have a .NET Core console app that prints formatted tables with relatively long rows. If the console width is too narrow to display the table, I increase it via `Console.WindowWidth`. This works in a `cmd.exe` window but not (yet) inside Windows Terminal.
claunia commented 2026-01-31 00:55:22 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 9, 2020):

Would I be correct to assume that this issue also encompasses non-VT resizing?

I think that's the intention, yes (assuming it's decided that we do anything about this at all). The original bug report that prompted this issue was a Windows app using SetConsoleScreenBufferSize (see issue #5079). I was just saying that we needed to fix the VT sequences first, because that's how the resizing information would be communicated to the Windows Terminal.

@j4james commented on GitHub (Apr 9, 2020): > Would I be correct to assume that this issue also encompasses non-VT resizing? I think that's the intention, yes (assuming it's decided that we do anything about this at all). The original bug report that prompted this issue was a Windows app using `SetConsoleScreenBufferSize` (see issue #5079). I was just saying that we needed to fix the VT sequences first, because that's how the resizing information would be communicated to the Windows Terminal.
claunia commented 2026-01-31 00:55:23 +00:00
Author
Owner
Copy Link

@luke1961 commented on GitHub (Apr 14, 2020):

Would I be correct to assume that this issue also encompasses non-VT resizing?

I think that's the intention, yes (assuming it's decided that we do anything about this at all). The original bug report that prompted this issue was a Windows app using SetConsoleScreenBufferSize (see issue #5079). I was just saying that we needed to fix the VT sequences first, because that's how the resizing information would be communicated to the Windows Terminal.

100% agreed. Fixing printf("\x1b[8;%d;%dt", nY, nX); is critical to address app-initiated resizing. This is very important to stay compatible with many apps that just count on running with a specific number of rows and columns. Some of these apps are usually configured to be launched from a batch batch file which includes a mode con lines=rrr cols=ccc statement to ensure proper buffer size. Of course the mode statement results in the escape sentence listed above sent to the Terminal.

@luke1961 commented on GitHub (Apr 14, 2020): > > Would I be correct to assume that this issue also encompasses non-VT resizing? > > I think that's the intention, yes (assuming it's decided that we do anything about this at all). The original bug report that prompted this issue was a Windows app using `SetConsoleScreenBufferSize` (see issue #5079). I was just saying that we needed to fix the VT sequences first, because that's how the resizing information would be communicated to the Windows Terminal. 100% agreed. Fixing `printf("\x1b[8;%d;%dt", nY, nX);` is critical to address app-initiated resizing. This is very important to stay compatible with many apps that just count on running with a specific number of rows and columns. Some of these apps are usually configured to be launched from a batch batch file which includes a `mode con lines=rrr cols=ccc` statement to ensure proper buffer size. Of course the `mode` statement results in the escape sentence listed above sent to the Terminal.
claunia commented 2026-01-31 00:55:23 +00:00
Author
Owner
Copy Link

@alexrp commented on GitHub (Oct 11, 2020):

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.

@alexrp commented on GitHub (Oct 11, 2020): 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.
claunia commented 2026-01-31 00:55:24 +00:00
Author
Owner
Copy Link

@pjfarleyiii commented on GitHub (Dec 29, 2020):

I am the author of #8673 which was closed as a duplicate of this issue. I understand the discussion here concerning the intricacies of what other tabs in Terminal do / see and when, but my interest is from the POV of a simple text-based application that wants to ensure an appropriate terminal height and width (in characters) depending on startup options specified by the application user.

In the old CMD.EXE console (which is not tabbed) I can just print the "CSI 8; lines; cols t" sequence and have the window resize immediately. If you can provide that support more quickly for only the "single tab open" case my needs would be satisfied.

Can a single-tab-only solution be considered for more rapid update as an intermediate step pending multi-tab design and implementation solution(s)?

Regards,

Peter

P.S. -- Whatever the mechanism, WSL screens (which I was given to understand are using MS Terminal) DO respond to the "CSI 8; lines; cols t" sequence and immediately resize the WSL console window. Tested with Ubuntu 20.04LTS and Debian 10 WSL instances.

@pjfarleyiii commented on GitHub (Dec 29, 2020): I am the author of #8673 which was closed as a duplicate of this issue. I understand the discussion here concerning the intricacies of what other tabs in Terminal do / see and when, but my interest is from the POV of a simple text-based application that wants to ensure an appropriate terminal height and width (in characters) depending on startup options specified by the application user. In the old CMD.EXE console (which is not tabbed) I can just print the "CSI 8; lines; cols t" sequence and have the window resize immediately. If you can provide that support more quickly for only the "single tab open" case my needs would be satisfied. Can a single-tab-only solution be considered for more rapid update as an intermediate step pending multi-tab design and implementation solution(s)? Regards, Peter P.S. -- Whatever the mechanism, WSL screens (which I was given to understand are using MS Terminal) DO respond to the "CSI 8; lines; cols t" sequence and immediately resize the WSL console window. Tested with Ubuntu 20.04LTS and Debian 10 WSL instances.
claunia commented 2026-01-31 00:55:24 +00:00
Author
Owner
Copy Link

@teobugslayer commented on GitHub (Apr 3, 2022):

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:

  1. Check the WT_SESSION environment variable
  2. If set, perform FreeConsole() / AllocConsole().

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:

  • Option 4. Add an executable manifest option, similar to the supportedOS option. Using it, app developers and advanced users can explicitly request the old conhost, the new terminal, or leave it as a user choice. Also, add a Windows API call which can set this, if possible.
  • Option 5. When an app resizes its console, perform the following:
    1. detach the tab from the current window, if there are other tabs
    2. create a new WT window and show the app in it with the requested console size
    3. optionally, show the console size in the window title, so that the user has visual indication that this is a special window
    4. optionally, allow only apps with explicitly set console size which match the existing one to be attached as tabs to this WT window.
@teobugslayer commented on GitHub (Apr 3, 2022): 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: 1. Check the WT_SESSION environment variable 2. If set, perform FreeConsole() / AllocConsole(). 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: * Option 4. Add an executable manifest option, similar to the [supportedOS](https://docs.microsoft.com/en-us/windows/win32/sysinfo/targeting-your-application-at-windows-8-1) option. Using it, app developers and advanced users can explicitly request the old conhost, the new terminal, or leave it as a user choice. Also, add a Windows API call which can set this, if possible. * Option 5. When an app resizes its console, perform the following: 1. detach the tab from the current window, if there are other tabs 2. create a new WT window and show the app in it with the requested console size 3. optionally, show the console size in the window title, so that the user has visual indication that this is a special window 4. optionally, allow only apps with explicitly set console size which match the existing one to be attached as tabs to this WT window.
claunia commented 2026-01-31 00:55:24 +00:00
Author
Owner
Copy Link

@Jibun-no-Kage commented on GitHub (May 8, 2022):

Any progress on this issue?

@Jibun-no-Kage commented on GitHub (May 8, 2022): Any progress on this issue?
claunia commented 2026-01-31 00:55:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 9, 2022):

@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.

@zadjii-msft commented on GitHub (May 9, 2022): @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.
claunia commented 2026-01-31 00:55:25 +00:00
Author
Owner
Copy Link

@vladdeSV commented on GitHub (May 9, 2022):

[…] 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.

(Off-topic)

From my previous interactions with Microsoft repos, I've understood is that thumbs up is not a preferred way to measure because of the lack information provided with a single emoji; comments provided more information.

@zadjii-msft Is this the new preferred way generally, or just for this issue?

@vladdeSV commented on GitHub (May 9, 2022): > […] 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. (Off-topic) From my previous interactions with Microsoft repos, I've understood is that thumbs up is not a preferred way to measure because of the lack information provided with a single emoji; comments provided more information. @zadjii-msft Is this the new preferred way generally, or just for this issue?
claunia commented 2026-01-31 00:55:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 9, 2022):

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.

@zadjii-msft commented on GitHub (May 9, 2022): 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](https://c.tenor.com/aeV80XD4CSgAAAAd/guidlines-pirates-of-the-caribbean.gif). 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.
claunia commented 2026-01-31 00:55:25 +00:00
Author
Owner
Copy Link

@Jibun-no-Kage commented on GitHub (May 9, 2022):

Ah, thanks for the update. Yes,will click the thumbs up.

@Jibun-no-Kage commented on GitHub (May 9, 2022): Ah, thanks for the update. Yes,will click the thumbs up.
claunia commented 2026-01-31 00:55:26 +00:00
Author
Owner
Copy Link

@JoezCodes101 commented on GitHub (Oct 14, 2022):

Any progress updates?

@JoezCodes101 commented on GitHub (Oct 14, 2022): Any progress updates?
claunia commented 2026-01-31 00:55:26 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 14, 2022):

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
image
That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

@zadjii-msft commented on GitHub (Oct 14, 2022): Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️
claunia commented 2026-01-31 00:55:26 +00:00
Author
Owner
Copy Link

@doverton12 commented on GitHub (Oct 26, 2022):

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.?

@doverton12 commented on GitHub (Oct 26, 2022): 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.?
claunia commented 2026-01-31 00:55:26 +00:00
Author
Owner
Copy Link

@BlueOnBLack commented on GitHub (Dec 3, 2022):

Optional solution
https://pastebin.com/8UERXCJr

and use this script, to get Terminal PID
https://pastebin.com/z796Nwak

@BlueOnBLack commented on GitHub (Dec 3, 2022): Optional solution https://pastebin.com/8UERXCJr and use this script, to get Terminal PID https://pastebin.com/z796Nwak
claunia commented 2026-01-31 00:55:27 +00:00
Author
Owner
Copy Link

@BlueOnBLack commented on GitHub (Dec 3, 2022):

let's assume you are using this
mode con cols=88 lines=23

to use the new api ...
make function that does this

set /a colss=%1*9
set /a lines=%2*22
set PROC_ID=Terminal_Process_ID
PS -nop -file .........

another good option is to use cmdow
https://ritchielawrence.github.io/cmdow/
for that you need to use MainWindowHandle value
@(Get-process | Where Id -EQ !ProcessId!).MainWindowHandle
and convert it into hex with Hex2Dec utility or try this article
https://shellgeek.com/powershell-convert-decimal-to-hex
and try something like this
"%cmdow%" !output:~0,2!0!output:~2! /SIZ !colss! !lines!

BTW
Cmdow will accept only this regex 0x0+HEX_VALUE

@BlueOnBLack commented on GitHub (Dec 3, 2022): let's assume you are using this mode con cols=88 lines=23 to use the new api ... make function that does this ``` set /a colss=%1*9 set /a lines=%2*22 set PROC_ID=Terminal_Process_ID PS -nop -file ......... ``` another good option is to use cmdow `https://ritchielawrence.github.io/cmdow/` for that you need to use MainWindowHandle value `@(Get-process | Where Id -EQ !ProcessId!).MainWindowHandle` and convert it into hex with Hex2Dec utility or try this article `https://shellgeek.com/powershell-convert-decimal-to-hex` and try something like this `"%cmdow%" !output:~0,2!0!output:~2! /SIZ !colss! !lines!` BTW Cmdow will accept only this regex 0x0+HEX_VALUE
claunia commented 2026-01-31 00:55:27 +00:00
Author
Owner
Copy Link

@BDisp commented on GitHub (Jan 3, 2023):

printf "\e[8;10;10t"

This escape sequence is for resize the visible window. I would like to know what is the escape sequence for resize the screen buffer, please. Thanks.

@BDisp commented on GitHub (Jan 3, 2023): > printf "\e[8;10;10t" This escape sequence is for resize the visible window. I would like to know what is the escape sequence for resize the screen buffer, please. Thanks.
claunia commented 2026-01-31 00:55:27 +00:00
Author
Owner
Copy Link

@BDisp commented on GitHub (Jan 22, 2023):

@j4james commented in https://github.com/microsoft/terminal/issues/14568#issuecomment-1353563545:

I think the only issue here is that we don't support screen size changes in Windows Terminal. If I remember correctly, the SetConsoleScreenBufferInfoEx call will change the size on the conhost side of the conpty connection, but that change isn't passed on to the conpty client. As a result, the two get out of sync and things can get weird. This problem is tracked in issue https://github.com/microsoft/terminal/issues/5094.

As I mention in #14568 the lack in the possibility of support screen size changes in Windows Terminal, prevents some feature with scrolling and this is very limited. I think if a app want to handle the buffer size then must provide code for that, otherwise its output will be handled by the terminal default behavior. Only the current tab can handle the windows size manipulation, to avoid windows been resized all the time if another tab is also change its size.

@BDisp commented on GitHub (Jan 22, 2023): @j4james commented in https://github.com/microsoft/terminal/issues/14568#issuecomment-1353563545: > I think the only issue here is that we don't support screen size changes in Windows Terminal. If I remember correctly, the SetConsoleScreenBufferInfoEx call will change the size on the conhost side of the conpty connection, but that change isn't passed on to the conpty client. As a result, the two get out of sync and things can get weird. This problem is tracked in issue https://github.com/microsoft/terminal/issues/5094. As I mention in #14568 the lack in the possibility of support screen size changes in `Windows Terminal`, prevents some feature with scrolling and this is very limited. I think if a app want to handle the buffer size then must provide code for that, otherwise its output will be handled by the terminal default behavior. Only the current tab can handle the windows size manipulation, to avoid windows been resized all the time if another tab is also change its size.
claunia commented 2026-01-31 00:55:27 +00:00
Author
Owner
Copy Link

@adithya-s-sekhar commented on GitHub (Apr 9, 2023):

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.

@adithya-s-sekhar commented on GitHub (Apr 9, 2023): 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.
claunia commented 2026-01-31 00:55:28 +00:00
Author
Owner
Copy Link

@2lag commented on GitHub (Apr 21, 2023):

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.

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.

@2lag commented on GitHub (Apr 21, 2023): > 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. 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.
claunia commented 2026-01-31 00:55:28 +00:00
Author
Owner
Copy Link

@adithya-s-sekhar commented on GitHub (Apr 22, 2023):

@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.

@adithya-s-sekhar commented on GitHub (Apr 22, 2023): @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.
claunia commented 2026-01-31 00:55:28 +00:00
Author
Owner
Copy Link

@TheUbMunster commented on GitHub (Jun 19, 2024):

I really don't know much about the implementation differences, but is the new slick Terminal app really plagued with a bunch of non-functionality? I've been trying to work around this (even hacky-ish winapi stuff), but have not yet found anything satisfactory.

Is this ever going to be fixed?

@TheUbMunster commented on GitHub (Jun 19, 2024): I really don't know much about the implementation differences, but is the new slick `Terminal` app really plagued with a bunch of non-functionality? I've been trying to work around this (even hacky-ish winapi stuff), but have not yet found anything satisfactory. Is this ever going to be fixed?
claunia commented 2026-01-31 00:55:28 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 19, 2024):

I really don't know much about the implementation differences, but is the new slick Terminal app really plagued with a bunch of non-functionality?

Part of it is intentional for the sake of simplicity. The new terminal hosts multiple terminal applications simultaneously in the same window and it's not immediately obvious if one application should be allowed to decide the window size of another in another tab or pane. This isn't impossible to solve (for instance we could make it so that the focused tab gets to decide this, if there aren't any split panes), but I think one can see how ignoring client requested resizes makes this a lot simpler...

Is this ever going to be fixed?

In fairness to everyone we usually prioritize work on the things that receive the most attention from our users (fwiw we're only around 2 devs on this project). While this issue is pretty bad overall, it's unfortunately not among the most important ones.

But regarding your question, I think the answer is generally "yes". Work on this however isn't currently planned. Work around this on the other hand is currently ongoing (specifically the translation of window resizes to CSI t, and how resizes are fed back to the terminal), and I expect that this work should make it easier to address this issue in the future.

@lhecker commented on GitHub (Jun 19, 2024): > I really don't know much about the implementation differences, but is the new slick `Terminal` app really plagued with a bunch of non-functionality? Part of it is intentional for the sake of simplicity. The new terminal hosts multiple terminal applications simultaneously in the same window and it's not immediately obvious if one application should be allowed to decide the window size of another in another tab or pane. This isn't impossible to solve (for instance we could make it so that the focused tab gets to decide this, if there aren't any split panes), but I think one can see how ignoring client requested resizes makes this a lot simpler... > Is this ever going to be fixed? In fairness to everyone we usually prioritize work on the things that receive the most attention from our users (fwiw we're only around 2 devs on this project). While this issue is pretty bad overall, it's unfortunately not among the most important ones. But regarding your question, I think the answer is generally "yes". Work on this however isn't currently planned. Work _around_ this on the other hand is currently ongoing (specifically the translation of window resizes to CSI t, and how resizes are fed back to the terminal), and I expect that this work should make it easier to address this issue in the future.
claunia commented 2026-01-31 00:55:28 +00:00
Author
Owner
Copy Link

@LurkingKiwi commented on GitHub (Jul 11, 2024):

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:

  • Option 4. Add an executable manifest option, similar to the supportedOS option. Using it, app developers and advanced users can explicitly request the old conhost, the new terminal, or leave it as a user choice. Also, add a Windows API call which can set this, if possible.

I also support an app which enforces window and buffer sizes using the old console API.
We have had to keep evolving as MS console changes all seem to be controlled by an all-or-nothing switch. It was old conhost/new conhost as a global setting, now its conhost/terminal, and ignoring the window size options destroys the app.
A manifest option to choose the old conhost is an excellent idea, and I was trying to find the (non-existent) option when I found this issue.

@LurkingKiwi commented on GitHub (Jul 11, 2024): > 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: ><snip> > * Option 4. Add an executable manifest option, similar to the [supportedOS](https://docs.microsoft.com/en-us/windows/win32/sysinfo/targeting-your-application-at-windows-8-1) option. Using it, app developers and advanced users can explicitly request the old conhost, the new terminal, or leave it as a user choice. Also, add a Windows API call which can set this, if possible. I also support an app which enforces window and buffer sizes using the old console API. We have had to keep evolving as MS console changes all seem to be controlled by an all-or-nothing switch. It was old conhost/new conhost as a global setting, now its conhost/terminal, and ignoring the window size options destroys the app. A manifest option to choose the old conhost is an excellent idea, and I was trying to find the (non-existent) option when I found this issue.
claunia commented 2026-01-31 00:55:28 +00:00
Author
Owner
Copy Link

@BDisp commented on GitHub (Nov 1, 2024):

In Windows Terminal Preview version 1.22.2912.0 it is no longer possible to resize the buffer. In version 1.21.2911.0 it is working fine with buffer resizing.

@BDisp commented on GitHub (Nov 1, 2024): In Windows Terminal Preview version 1.22.2912.0 it is no longer possible to resize the buffer. In version 1.21.2911.0 it is working fine with buffer resizing.
claunia commented 2026-01-31 00:55:29 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Nov 4, 2024):

@BDisp I don't remember CSI t being supported in either 1.21 or 1.22.
Reading through the linked gui-cs PR I can see that there are various issues with 1.22 being discussed, but I don't fully understand it, as I'm unfamiliar with gui-cs. So, could you please be more specific what's broken and how to reproduce it? I'd be happy to help. 🙂
If it's unrelated with CSI t though, please consider creating a new issue. Just some repro steps and perhaps a screenshot or two should already be sufficient (although it's of course always helpful if you can provide even more information).

Edit: I should mention that the issues you're experiencing are extremely likely due to our new ConPTY implementation (the translation layer between console APIs and VT). That's one of the major new features in 1.22.

@lhecker commented on GitHub (Nov 4, 2024): @BDisp I don't remember CSI t being supported in either 1.21 or 1.22. Reading through the linked gui-cs PR I can see that there are various issues with 1.22 being discussed, but I don't fully understand it, as I'm unfamiliar with gui-cs. So, could you please be more specific what's broken and how to reproduce it? I'd be happy to help. 🙂 If it's unrelated with CSI t though, please consider creating a new issue. Just some repro steps and perhaps a screenshot or two should already be sufficient (although it's of course always helpful if you can provide even more information). Edit: I should mention that the issues you're experiencing are extremely likely due to our new ConPTY implementation (the translation layer between console APIs and VT). That's one of the major new features in 1.22.
claunia commented 2026-01-31 00:55:29 +00:00
Author
Owner
Copy Link

@BDisp commented on GitHub (Nov 4, 2024):

Thanks for your attention @lhecker. On Windows 11 using Win32 API, like the SetConsoleScreenBufferInfoEx or even using CSI t I cannot now resize the screen buffer and it remain greater than the terminal window size. Thus allow the user to scroll using the scroll bar which we don't want for not let the user see corrupted buffer. If is there an alternative to change the buffer size to the same window size I would appreciate any information, thanks.

@BDisp commented on GitHub (Nov 4, 2024): Thanks for your attention @lhecker. On Windows 11 using Win32 API, like the `SetConsoleScreenBufferInfoEx` or even using `CSI t` I cannot now resize the screen buffer and it remain greater than the terminal window size. Thus allow the user to scroll using the scroll bar which we don't want for not let the user see corrupted buffer. If is there an alternative to change the buffer size to the same window size I would appreciate any information, thanks.
claunia commented 2026-01-31 00:55:29 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Nov 4, 2024):

Are you by any chance looking for something like the "alternate screen buffer"? You can enter it by emitting \x1b[?1049h and exit it by emitting \x1b[?1049l. All versions of Windows that are still officially supported support that sequence.

@lhecker commented on GitHub (Nov 4, 2024): Are you by any chance looking for something like the "alternate screen buffer"? You can enter it by emitting `\x1b[?1049h` and exit it by emitting `\x1b[?1049l`. All versions of Windows that are still officially supported support that sequence.
claunia commented 2026-01-31 00:55:29 +00:00
Author
Owner
Copy Link

@BDisp commented on GitHub (Nov 4, 2024):

Are you by any chance looking for something like the "alternate screen buffer"? You can enter it by emitting \x1b[?1049h and exit it by emitting \x1b[?1049l. All versions of Windows that are still officially supported support that sequence.

Yes that is done on enter and exit. But during the execution resize the window isn't resizing the buffer size using the Win32 API. I also tried with the escape sequence but also without success.

Here is a screenshot. Maximize the window and restore doesn't not set anymore the buffer size with the same size of the window:

Image

@BDisp commented on GitHub (Nov 4, 2024): > Are you by any chance looking for something like the "alternate screen buffer"? You can enter it by emitting `\x1b[?1049h` and exit it by emitting `\x1b[?1049l`. All versions of Windows that are still officially supported support that sequence. Yes that is done on enter and exit. But during the execution resize the window isn't resizing the buffer size using the Win32 API. I also tried with the escape sequence but also without success. Here is a screenshot. Maximize the window and restore doesn't not set anymore the buffer size with the same size of the window: ![Image](https://github.com/user-attachments/assets/2d6e0fd6-f901-4545-8952-e5ee2a2c98e0)
claunia commented 2026-01-31 00:55:29 +00:00
Author
Owner
Copy Link

@BDisp commented on GitHub (Nov 4, 2024):

Only to remember that in the WT version 1.21 the resize is working well. Only in the 1.22 (Preview) version this issue is happening.

@BDisp commented on GitHub (Nov 4, 2024): Only to remember that in the WT version 1.21 the resize is working well. Only in the 1.22 (Preview) version this issue is happening.
claunia commented 2026-01-31 00:55:30 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Nov 4, 2024):

We should continue this discussion in another issue, since there are over 20 people subscribed to this one. Do you mind filing an issue? It would be great if you could include reproduction steps.

BTW: I'm also confused why you mention the need to resize the buffer. The terminal resizes the buffer for you when the window size changes. There should be no need for you to call anything (nor use CSI t) during a maximize/restore. The alternate screen buffer always has the size of the window.

@lhecker commented on GitHub (Nov 4, 2024): We should continue this discussion in another issue, since there are over 20 people subscribed to this one. Do you mind filing an issue? It would be great if you could include reproduction steps. BTW: I'm also confused why you mention the need to resize the buffer. The terminal resizes the buffer for you when the window size changes. There should be no need for you to call anything (nor use CSI t) during a maximize/restore. The alternate screen buffer always has the size of the window.
claunia commented 2026-01-31 00:55:30 +00:00
Author
Owner
Copy Link

@ClaireCJS commented on GitHub (Nov 5, 2024):

Are you by any chance looking for something like the "alternate screen buffer"? You can enter it by emitting \x1b[?1049h and exit it by emitting \x1b[?1049l. All versions of Windows that are still officially supported support that sequence.

You know.. I read the entire VT100 manual and hand-tried every single feasible one in the manual. I don't think I remember that one but maybe I just didn't understand it at the time.

@ClaireCJS commented on GitHub (Nov 5, 2024): > Are you by any chance looking for something like the "alternate screen buffer"? You can enter it by emitting `\x1b[?1049h` and exit it by emitting `\x1b[?1049l`. All versions of Windows that are still officially supported support that sequence. You know.. I read the entire VT100 manual and hand-tried every single feasible one in the manual. I don't think I remember that one but maybe I just didn't understand it at the time.
claunia commented 2026-01-31 00:55:30 +00:00
Author
Owner
Copy Link

@Jibun-no-Kage commented on GitHub (Nov 5, 2024):

Check the VT220 Manual. There were a lot, literally a lot of changes between VT100 and VT220 standards. I want to say, if memory services, it was in the VT220 standard that buffering options were enhanced.

@Jibun-no-Kage commented on GitHub (Nov 5, 2024): Check the VT220 Manual. There were a lot, literally a lot of changes between VT100 and VT220 standards. I want to say, if memory services, it was in the VT220 standard that buffering options were enhanced.
claunia commented 2026-01-31 00:55:30 +00:00
Author
Owner
Copy Link

@ClaireCJS commented on GitHub (Nov 5, 2024):

Check the VT220 Manual. There were a lot, literally a lot of changes between VT100 and VT220 standards. I want to say, if memory services, it was in the VT220 standard that buffering options were enhanced.

I guess every good story has its sequel 🤣 I'll have to do that, thanks for the recommendation!

@ClaireCJS commented on GitHub (Nov 5, 2024): > Check the VT220 Manual. There were a lot, literally a lot of changes between VT100 and VT220 standards. I want to say, if memory services, it was in the VT220 standard that buffering options were enhanced. I guess every good story has its sequel 🤣 I'll have to do that, thanks for the recommendation!
claunia commented 2026-01-31 00:55:30 +00:00
Author
Owner
Copy Link

@Joachim-Otahal commented on GitHub (Jun 16, 2025):

Just subscribing since I cannot use the new Terminal just because of this.
A simple mode con cols=50 fails... Or a simple
$host.UI.RawUI.BufferSize = @{Width=50;Height=$Host.UI.RawUI.BufferSize.Height}
$host.UI.RawUI.WindowSize = @{Width=50;Height=$Host.UI.RawUI.WindowSize.Height}

@Joachim-Otahal commented on GitHub (Jun 16, 2025): Just subscribing since I cannot use the new Terminal just because of this. A simple mode con cols=50 fails... Or a simple $host.UI.RawUI.BufferSize = @{Width=50;Height=$Host.UI.RawUI.BufferSize.Height} $host.UI.RawUI.WindowSize = @{Width=50;Height=$Host.UI.RawUI.WindowSize.Height}
claunia commented 2026-01-31 00:55:30 +00:00
Author
Owner
Copy Link

@OZ1 commented on GitHub (Sep 14, 2025):

After 5 years, the Console.SetWindowSize(117, 7) still doesn't work.

@OZ1 commented on GitHub (Sep 14, 2025): After 5 years, the Console.SetWindowSize(117, 7) still doesn't work.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT In-PR Issue-Task Priority-2 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#7111
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?