starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Add a setting for in-order tab traversal with the tab switcher #11148

New Issue
Closed
opened 2026-01-31 02:39:54 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 02:39:54 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Oct 23, 2020).

Originally assigned to: @zadjii-msft on GitHub.

We had a long discussion about this in Teams the other day, trying move it to Github to make sure we don't lose it. Expando the below expand to see the entire line of reasoning that got us here.

Unfiltered chat

tbh, I like the tab switcher (with previewing), and in-order history. I also don't think it's out of the realm of possibility for someone to want MRU order, no switcher. So I guess I do think there should be two bools - useTabSwitcher and tabSwitchOrder

For me I like just having useTabSwitcher and have it only be MRU. If people want in order, the tab switcher feels redundant? So they could just disable it?

I disagree - I'm a tabWidth:equal kind of guy, and I like the tab switcher for my longer tab titles:
But I also like in-order traversal, and can't stand MRU traversal. So I want both the switcher and in-order at the same time.
Plus, let's consider when panes are in the tab switcher too. I dont want to be forced to use MRU switching if I want to be able to use the tab switcher to navigate through panes.

Oh yeah those are excellent points. Could we combine the two bools to just one? Like, "useTabSwitcher": "MRU", "inOrder", "off" or something?

i'm in the "defer it until later" camp. tab switcher is always MRU until more than one user (hi mike ;P) complains
firefox did this. it's either tab-row in-order no-popup, or with-popup MRU
and i explicitly always go knife the popup as early as humanly possible when i install it fresh
my rationale is really just "looks like we've got MRU in PR today; making it configurable would complicate the PR and delay the feature for the people who are mad at us"
​ > we should of course go add the setting later! I'm just thinking this is an area for incremental improvement. Do it one way, see how people react, add the new thing, etc etc etc

I can get behind the wait and see approach - changing the setting is relatively straightforward, so if we do get enough requests it'll be a short turnaround time. I agree tho that the option for inorderATS makes a lot of sense when pane switching comes into the picture. maybe i can make a secret setting for mike to use inorderATS (tongueout)

lol let's merge MRU for now and I'll ship the setting (tongueout)
ah shiz tho, what's the default value for the setting?
tabSwitchOrder: inOrder|mostRecentlyUsed
right now we're using inOrder as the "default". After your current PR, the switcher will default to MRU, and after my PR, the switcher will default to inOrder, with the option for MRU

the ATS is enabled by default, so I think MRU-ATS should be the default fresh install behavior.

I'm pretty confident if we do that, then people are gonna complain about us breaking their next/prev tab muscle memory

We also need to comport tabSwitchOrder with useTabSwitcher. The first only makes sense with the second. You can pry “no popup, screen order” from my cold dead hands

image
/spec

But depending on how we configure the defaults, we’re going to keep our users on a horrible treadmill where they need to keep adding new disablement settings just to keep up with us
The top right box just looks like “terminal is broken”
Should it be a possible state at all?

tbh i like Kayla's suggestion of combining the two to make useTabSwitcher an enum. i tried doing MRU switching with no popup, i didn't know what tab i was getting next

idk, there's a bunch of people who all want MRU order switching, and TBH I've never seen a MRU popup before in another app. So presumably?

Huh, alt tab is MRU and ctr tab in both Visual Studios is MRU+popup
​

I agree that it's an insane behavior, but
​>
okay yea I guess alt tab counts as a popup

like regardless of which box we choose, some set of people will change their settings. If we choose box N (clockwise from top-left) as the default:

  1. Nothings changed from the pre-ATS build. People who want MRU or ATS need to change settings
  2. Everyone is unhappy and changes their settings
  3. Everyone with muscle memory of in-order switching needs to change the setting
  4. Everyone who wants MRU needs to change the setting

I think it's usually best to have people opt-in to new "muscle" behavior like this. The switcher could be on by default b/c it doesn't affect muscle memory, but MRU would

when changing defaults there's also the consideration of "what do we want our fresh install experience to be". I don't particularly care if it's inorder or mru bc I don't mind changing my settings, but I think that if we go with inorder, it should use no popup by default, and if we go with mru, it should use a popup. I feel like these two combos are the most common combos seen in a wide range of apps.
I feel like mru vs in-order muscle memory has already been developed through a user's experience with other apps, which is probably why they get angerey at us for not implementing an order they've used their entire life (mru) (laugh)

Yeah I’m on board with all these assertions. Well said, both of you!
Should it actually be more like “tabSwitchOrder: default, inorder and mru” and default is “the presence or absence of the tab switcher decides”?
We have had two releases to build muscle memory with ATS versus the twelve for the normal inorder switcher. Just a thought
​

default is “the presence or absence of the tab switcher decides”?

ooooooh now there's a thought

So I think the conclusion was

"tabSwitchOrder": "default|inorder|mru"
  • default is “the presence or absence of the tab switcher decides”. So,
    1. "tabSwitchOrder":"default", "useTabSwitcher":true is MRU switching with the tab switcher
    2. "tabSwitchOrder":"default", "useTabSwitcher":false is in-order switching without the tab switcher, basically what the behavior was before the ATS.
    3. "tabSwitchOrder":"inOrder", "useTabSwitcher":true is in-order switching with the tab switcher
    4. "tabSwitchOrder":"inOrder", "useTabSwitcher":false is in-order switching without the tab switcher, basically what the behavior was before the ATS, and the same as case 2.
    5. "tabSwitchOrder":"mru", "useTabSwitcher":true is MRU switching with the tab switcher, and the same as case 1
    6. "tabSwitchOrder":"mru", "useTabSwitcher":false is MRU switching without the tab switcher
Originally created by @zadjii-msft on GitHub (Oct 23, 2020). Originally assigned to: @zadjii-msft on GitHub. We had a long discussion about this in Teams the other day, trying move it to Github to make sure we don't lose it. Expando the below expand to see the entire line of reasoning that got us here. <details> <summary>Unfiltered chat</summary> > tbh, I like the tab switcher (with previewing), and in-order history. I also don't think it's out of the realm of possibility for someone to want MRU order, no switcher. So I guess I do think there should be two bools - useTabSwitcher and tabSwitchOrder > For me I like just having useTabSwitcher and have it only be MRU. If people want in order, the tab switcher feels redundant? So they could just disable it? > I disagree - I'm a tabWidth:equal kind of guy, and I like the tab switcher for my longer tab titles: > But I also like in-order traversal, and can't stand MRU traversal. So I want both the switcher and in-order at the same time. > Plus, let's consider when panes are in the tab switcher too. I dont want to be forced to use MRU switching if I want to be able to use the tab switcher to navigate through panes. > Oh yeah those are excellent points. Could we combine the two bools to just one? Like, "useTabSwitcher": "MRU", "inOrder", "off" or something? > i'm in the "defer it until later" camp. tab switcher is always MRU until more than one user (hi mike ;P) complains > firefox did this. it's either tab-row in-order no-popup, or with-popup MRU > and i explicitly always go knife the popup as early as humanly possible when i install it fresh > my rationale is really just "looks like we've got MRU in PR today; making it configurable would complicate the PR and delay the feature for the people who are mad at us" ​ > we should of course go add the setting later! I'm just thinking this is an area for incremental improvement. Do it one way, see how people react, add the new thing, etc etc etc > I can get behind the wait and see approach - changing the setting is relatively straightforward, so if we do get enough requests it'll be a short turnaround time. I agree tho that the option for inorderATS makes a lot of sense when pane switching comes into the picture. maybe i can make a secret setting for mike to use inorderATS (tongueout) > lol let's merge MRU for now and I'll ship the setting (tongueout) > ah shiz tho, what's the default value for the setting? > ```tabSwitchOrder: inOrder|mostRecentlyUsed``` > right now we're using inOrder as the "default". After your current PR, the switcher will default to MRU, and after my PR, the switcher will default to inOrder, with the option for MRU > the ATS is enabled by default, so I think MRU-ATS should be the default fresh install behavior. > I'm pretty confident if we do that, then people are gonna complain about us breaking their next/prev tab muscle memory > We also need to comport tabSwitchOrder with useTabSwitcher. The first only makes sense with the second. You can pry “no popup, screen order” from my cold dead hands > ![image](https://user-images.githubusercontent.com/18356694/97011762-b4ad9e00-150c-11eb-91a7-ed7f803bca5a.png) > /spec > But depending on how we configure the defaults, we’re going to keep our users on a horrible treadmill where they need to keep adding new disablement settings just to keep up with us > The top right box just looks like “terminal is broken” > Should it be a possible state at all? > tbh i like Kayla's suggestion of combining the two to make useTabSwitcher an enum. i tried doing MRU switching with no popup, i didn't know what tab i was getting next > idk, there's a bunch of people who all want MRU order switching, and TBH I've never seen a MRU popup before in another app. So presumably? > Huh, alt tab is MRU and ctr tab in both Visual Studios is MRU+popup ​ > I agree that it's an insane behavior, but ​> > okay yea I guess alt tab counts as a popup > > like regardless of which box we choose, some set of people will change their settings. If we choose box N (clockwise from top-left) as the default: > > 1. Nothings changed from the pre-ATS build. People who want MRU or ATS need to change settings > 2. Everyone is unhappy and changes their settings > 3. Everyone with muscle memory of in-order switching needs to change the setting > 4. Everyone who wants MRU needs to change the setting > > I think it's usually best to have people opt-in to new "muscle" behavior like this. The switcher could be on by default b/c it doesn't affect muscle memory, but MRU would > when changing defaults there's also the consideration of "what do we want our fresh install experience to be". I don't particularly care if it's inorder or mru bc I don't mind changing my settings, but I think that if we go with inorder, it should use no popup by default, and if we go with mru, it should use a popup. I feel like these two combos are the most common combos seen in a wide range of apps. > I feel like mru vs in-order muscle memory has already been developed through a user's experience with other apps, which is probably why they get angerey at us for not implementing an order they've used their entire life (mru) (laugh) > Yeah I’m on board with all these assertions. Well said, both of you! > Should it actually be more like “tabSwitchOrder: default, inorder and mru” and default is “the presence or absence of the tab switcher decides”? > We have had two releases to build muscle memory with ATS versus the twelve for the normal inorder switcher. Just a thought ​ > > default is “the presence or absence of the tab switcher decides”? > > ooooooh now there's a thought </details> So I think the conclusion was ```json "tabSwitchOrder": "default|inorder|mru" ``` * `default` is “the presence or absence of the tab switcher decides”. So, 1. `"tabSwitchOrder":"default", "useTabSwitcher":true` is MRU switching with the tab switcher 2. `"tabSwitchOrder":"default", "useTabSwitcher":false` is in-order switching without the tab switcher, basically what the behavior was before the ATS. 3. `"tabSwitchOrder":"inOrder", "useTabSwitcher":true` is in-order switching with the tab switcher 4. `"tabSwitchOrder":"inOrder", "useTabSwitcher":false` is in-order switching without the tab switcher, basically what the behavior was before the ATS, and the same as case 2. 5. `"tabSwitchOrder":"mru", "useTabSwitcher":true` is MRU switching with the tab switcher, and the same as case 1 6. `"tabSwitchOrder":"mru", "useTabSwitcher":false` is MRU switching without the tab switcher
claunia added the Resolution-Fix-CommittedArea-SettingsIssue-TaskProduct-Terminal labels 2026-01-31 02:39:54 +00:00
claunia commented 2026-01-31 02:39:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 23, 2020):

Tentatively tossed into 1.5 - Since we're shipping MRU switching in this release (#7952), I think it might be a good story to have a bunch of ATS polish and customizations in this release, this included.

@zadjii-msft commented on GitHub (Oct 23, 2020): Tentatively tossed into 1.5 - Since we're shipping MRU switching in this release (#7952), I think it might be a good story to have a bunch of ATS polish and customizations in this release, this included.
claunia commented 2026-01-31 02:39:56 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Oct 23, 2020):

I feel I'd like Ctrl+Tab and Ctrl+Shift+Tab to switch in MRU order and show the tab switcher, but Ctrl+PageUp and Ctrl+PageDown to switch in display order and not show the tab switcher. (And Ctrl+Shift+PageUp and Ctrl+Shift+PageDown to reorder tabs as requested in https://github.com/microsoft/terminal/issues/3593.)

I can't be sure of my preference before trying the MRU tab switcher out, though.

@KalleOlaviNiemitalo commented on GitHub (Oct 23, 2020): I feel I'd like Ctrl+Tab and Ctrl+Shift+Tab to switch in MRU order and show the tab switcher, but Ctrl+PageUp and Ctrl+PageDown to switch in display order and not show the tab switcher. (And Ctrl+Shift+PageUp and Ctrl+Shift+PageDown to reorder tabs as requested in <https://github.com/microsoft/terminal/issues/3593>.) I can't be sure of my preference before trying the MRU tab switcher out, though.
claunia commented 2026-01-31 02:39:57 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 23, 2020):

Yea, I'm avoiding prescribing keybinds to this for now. I'd rather just provide the options now, without having to commit to how people use those options by default.

@zadjii-msft commented on GitHub (Oct 23, 2020): Yea, I'm avoiding prescribing keybinds to this for now. I'd rather just provide the options _now_, without having to commit to how people use those options by default.
claunia commented 2026-01-31 02:39:57 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Oct 23, 2020):

My point was that I might want to choose between MRU and display order in each key binding, rather than as a global setting.

@KalleOlaviNiemitalo commented on GitHub (Oct 23, 2020): My point was that I might want to choose between MRU and display order in each key binding, rather than as a global setting.
claunia commented 2026-01-31 02:39:57 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 23, 2020):

Oh my bad. IIRC that was originally the plan, but that was decided against. I'll summon @leonMSFT, he probably remembers where that discussion took place.

@zadjii-msft commented on GitHub (Oct 23, 2020): Oh my bad. IIRC that was originally the plan, but that was decided against. I'll summon @leonMSFT, he probably remembers where that discussion took place.
claunia commented 2026-01-31 02:39:57 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 23, 2020):

I suppose it could be

{ "action": "nextTab", "tabSwitcher": false|"inOrder"|"MRU" }

to override whatever the global useTabSwitcher setting is. If the tabSwticher parameter is missing, then use whatever the "default" value is (MRU for the tab switcher, in-order for not using the tab switcher).

false|"inOrder"|"MRU" as the enum would make the json parsing weird - I suppose true would be the same as MRU order.

Then I suppose


{ "action": "nextTab", "tabSwitcher": "inOrder" },
{ "action": "prevTab", "tabSwitcher": "MRU" }

what would that do? We should probably only apply the tabSwitcher setting when we'd be opening the switcher, not re-apply the setting while it's currently open.

@zadjii-msft commented on GitHub (Oct 23, 2020): I suppose it could be `{ "action": "nextTab", "tabSwitcher": false|"inOrder"|"MRU" }` to override whatever the global `useTabSwitcher` setting is. If the `tabSwticher` parameter is missing, then use whatever the "default" value is (MRU for the tab switcher, in-order for not using the tab switcher). `false|"inOrder"|"MRU"` as the enum would make the json parsing weird - I suppose `true` would be the same as MRU order. Then I suppose ```json { "action": "nextTab", "tabSwitcher": "inOrder" }, { "action": "prevTab", "tabSwitcher": "MRU" } ``` what would that do? We should probably only apply the `tabSwitcher` setting when we'd be opening the switcher, not re-apply the setting while it's currently open.
claunia commented 2026-01-31 02:39:57 +00:00
Author
Owner
Copy Link

@leonMSFT commented on GitHub (Oct 23, 2020):

IIRC a couple reasons we wanted to go with the global setting at first was for simplicity and to gauge how the community felt about only being able to choose one ordering over the other. Then if we get a bunch of feedback for further configurability we'd figure out exactly what that would look like (whether that's in the form of keybinding args or global settings).

@leonMSFT commented on GitHub (Oct 23, 2020): IIRC a couple reasons we wanted to go with the global setting at first was for simplicity and to gauge how the community felt about only being able to choose one ordering over the other. Then if we get a bunch of feedback for further configurability we'd figure out exactly what that would look like (whether that's in the form of keybinding args or global settings).
claunia commented 2026-01-31 02:39:58 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 27, 2020):

Oh fooey.

"tabSwitchOrder":"mru", "useTabSwitcher":false is MRU switching without the tab switcher

This case isn't actually possible today - the tab switcher needs to be open to be able to eat the consecutive keypresses while the modifier is pressed. Otherwise, this case is just going to toggle between the two MRU tabs, and makes it impossible to toggle to any of the other tabs.

So now we're looking at

image

does that even make sense to have a "default" then? The benefit we get from that is the default value could be default, and that would make sense for people who want both MRU with the tab switcher, and in-order w/o the switcher. People wouldn't have to opt-in to MRU, and it's only 1 setting to change to get to the old behavior.

If we got rid of default, then we'd have:
image

which is one setting change to either opt to in-order w/o the switcher, or one setting change to get to MRU with the switcher.

I guess I want to build a table with the nextTab/prevTab args as well, to make sure that's sensible.

@zadjii-msft commented on GitHub (Oct 27, 2020): Oh fooey. > "tabSwitchOrder":"mru", "useTabSwitcher":false is MRU switching without the tab switcher This case isn't actually possible today - the tab switcher needs to be open to be able to eat the consecutive keypresses while the modifier is pressed. Otherwise, this case is just going to toggle between the two MRU tabs, and makes it impossible to toggle to any of the other tabs. So now we're looking at ![image](https://user-images.githubusercontent.com/18356694/97331557-80f1b180-1847-11eb-8fe7-1ec877a878da.png) does that even make sense to have a "default" then? The benefit we get from that is the default value could be `default`, and that would make sense for people who want both MRU with the tab switcher, and in-order w/o the switcher. People wouldn't have to opt-in to MRU, and it's only 1 setting to change to get to the old behavior. If we got rid of `default`, then we'd have: ![image](https://user-images.githubusercontent.com/18356694/97331610-92d35480-1847-11eb-804a-c952c0ad68bb.png) which is one setting change to either opt to in-order w/o the switcher, or one setting change to get to MRU with the switcher. I guess I want to build a table with the `nextTab`/`prevTab` args as well, to make sure that's sensible.
claunia commented 2026-01-31 02:39:58 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 27, 2020):

After more discussion with the team, we realized - since the (MRU & no tab switcher) scenario is impossible, that we should just not make that a possible setting configuration. That makes the following the cleanest solution:

image

@zadjii-msft commented on GitHub (Oct 27, 2020): After more discussion with the team, we realized - since the (MRU & no tab switcher) scenario is impossible, that we should just not make that a possible setting configuration. That makes the following the cleanest solution: ![image](https://user-images.githubusercontent.com/18356694/97355036-4fd3aa00-1864-11eb-95c5-82f750c91c8a.png)
claunia commented 2026-01-31 02:39:58 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Nov 11, 2020):

:tada:This issue was addressed in #8076, which has now been successfully released as Windows Terminal Preview v1.5.3142.0.🎉

Handy links:

@ghost commented on GitHub (Nov 11, 2020): :tada:This issue was addressed in #8076, which has now been successfully released as `Windows Terminal Preview v1.5.3142.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.5.3142.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-31 02:39:58 +00:00
Author
Owner
Copy Link

@mlewand commented on GitHub (Nov 13, 2020):

Just for the record, the config option in the end got called tabSwitcherMode rather than tabSwitchOrder 😉

@mlewand commented on GitHub (Nov 13, 2020): Just for the record, the config option in the end got called `tabSwitcherMode` rather than `tabSwitchOrder` :wink:
claunia commented 2026-01-31 02:39:59 +00:00
Author
Owner
Copy Link

@ttk commented on GitHub (Jan 29, 2021):

I feel I'd like Ctrl+Tab and Ctrl+Shift+Tab to switch in MRU order and show the tab switcher, but Ctrl+PageUp and Ctrl+PageDown to switch in display order and not show the tab switcher

^ This is very important for me. MRU for Ctrl+Tab, and inOrder for nextTab and prevTab actions. That's how I have tab navigation setup in ConEmu and Chrome...so ideally I would like the same navigation hotkeys in Windows Terminal.

@ttk commented on GitHub (Jan 29, 2021): > I feel I'd like Ctrl+Tab and Ctrl+Shift+Tab to switch in MRU order and show the tab switcher, but Ctrl+PageUp and Ctrl+PageDown to switch in display order and not show the tab switcher ^ This is very important for me. MRU for Ctrl+Tab, and inOrder for nextTab and prevTab actions. That's how I have tab navigation setup in ConEmu and Chrome...so ideally I would like the same navigation hotkeys in Windows Terminal.
claunia commented 2026-01-31 02:39:59 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jan 29, 2021):

Yes, after trying the MRU tab switcher, I have indeed come to want both MRU and display orders for different key bindings.

Should file a separate feature request for that now, I suppose.

@KalleOlaviNiemitalo commented on GitHub (Jan 29, 2021): Yes, after trying the MRU tab switcher, I have indeed come to want both MRU and display orders for different key bindings. Should file a separate feature request for that now, I suppose.
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-Settings Issue-Task Product-Terminal Resolution-Fix-Committed
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#11148
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?