MRU useTabSwitcher prevents switching to tabs in left/right order

[johnburnett]

Description of the new feature/enhancement

I was excited for the MRU tab switching in 1.5, but it looks like the way it was designed there's no way to make it behave like Visual Studio (and other text editors) and support both MRU switching and next/prev (rather: left/right) switching at the same time. What I'm attempting:

• "ctrl+tab": switch to previous tab in MRU order
• "ctrl+shift+tab": switch to next tab in MRU order
• "ctrl+pgup": switch to the tab to the left
• "ctrl+pgdn": switch to the tab to the right

The current behavior with useTabSwitcher set to "disabled" or "inOrder" is:

• "ctrl+shift+tab": switch to tab to the left
• "ctrl+tab": switch to tab to the right

With useTabSwitcher set to "MRU" it's:

• "ctrl+tab": switch to previous tab in MRU order
• "ctrl+shift+tab": switch to next tab in MRU order

And in both cases, the "useTabSwitcher" setting changes the meaning of what the "nextTab" and "prevTab" commands actually do. This causes two undesirable effects:

• To get MRU ordering, you have to enable the tab switcher UI
• If you get MRU ordering, that's all you get (you lose the ability to navigate to tabs to the left/right)

Proposed technical implementation details (optional)

To fix, you could expose either four new commands:

• "leftTab"
• "rightTab"
• "mruNextTab"
• "mruPrevTab"

...or four new "direction" types to the "switchToTab" action:

• { "command": { "action": "switchToTab", "direction": "left" }, "keys": "ctrl+pgup" },
• { "command": { "action": "switchToTab", "direction": "right" }, "keys": "ctrl+pgdn" },
• { "command": { "action": "switchToTab", "direction": "mruPrev" }, "keys": "ctrl+tab" },
• { "command": { "action": "switchToTab", "direction": "mruNext" }, "keys": "ctrl+shift+tab" },

...which do exactly what they describe, and accomplishes the goal outlined above. None of these commands should be influenced by the "useTabSwitcher" setting (and the "nextTab/prevTab" commands would continue to be influenced to keep existing behavior).

[zadjii-msft]

You know, there was another thread around here where we were discussing the same exact thing, the same exact design, but I've lost it now. This is now the "I want to be able to use both MRU and in-order tab switching on different keys" thread.

Thanks!

EDIT: I found the original thread!
#8025 (comment)

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.

---

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

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:

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.

---

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:

[mg-christian-axelsson]

Chiming in second this. Glad to see MRU on ctrl+tab finally being available but having my ctrl+pgup and ctrl+pgdn also emit MRU instead of left/right behavior is incredibly confusing.

[Don-Vito]

@zadjii-msft - I can add support for:

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

WDYT?
Thought I am not sure what they should do if the tabswitcher is disabled.

[johnburnett]

Hmm, honestly feels less than ideal? Requiring the use of the tab switcher feels really odd from the outside, especially for those not wanting it?

[Don-Vito]

Hmm, honestly feels less than ideal? Requiring the use of the tab switcher feels really odd from the outside, especially for those not wanting it?

Guess I can make it:

{ "action": "nextTab", "tabSwitchOrder": "inOrder/MRU", "useTabSwitcher": true/false },

If not provided, use global settings.
WDYT?

[zadjii-msft]

{ "action": "nextTab", "tabSwitchOrder": "inOrder/MRU", "useTabSwitcher": true/false },

If not provided, use global settings.

That seems reasonable to me. Currently, {"action": "nextTab", "tabSwitchOrder": "mru", "useTabSwitcher": false} wouldn't work - we'd need to solve #9390 to make that work. But presuming that #9390 is eventually solvable, then this design is ready for that scenario.

My only question is what do we do when someone sets {"mru", false} before we fix #9390? Silently falling back to {"inOrder", false} feels wrong, {"mru", true} I suppose is a bit better. Maybe we could throw a warning when we're parsing the nextTab args that the {"mru", false} combo doesn't work, and we'll fall back to {"mru", true}? Then at least the user knows what's up.

[Don-Vito]

@zadjii-msft - as suggested in #9390, let's unify these tickets, they come together.

[johnburnett]

I'm not sure which ticket to respond to, so I'll stick with this one for now? Doing this:

{ "action": "nextTab", "tabSwitchOrder": "inOrder/MRU", "useTabSwitcher": true/false },

...doesn't look horrible, but including "useTabSwitcher" in this action definition still feels like combining two things that shouldn't be combined. I'm guessing this is because the existing "tabSwitcherMode" exists, and you are trying to override it?

Separately, I'd lean towards renaming "tabSwitchOrder" to something like "direction" or "order" instead (it took me a beat to recognize "tabSwitchOrder" had nothing to do with the tab switcher UI).

[Don-Vito]

After some hesitation, as I am not sure when I get to #9390, I decided to use the following format:

{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}

or

{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}

if you don't want tab switcher to show up.

It is actually aligned with the global setting. If we decide to add MRU mode with no tab switcher, we can simply add the new value to the enum (aka "disabledMRU"), and this will work for both commands and the settings.

[johnburnett]

tbh this setup feels... bizarre. But I guess that's the price of backwards compatibility? The "if we add MRU support without tab switcher" is also a slight cause for concern. Also wondering about the kinda-not-standard key bindings as well?

[zadjii-msft]

Also wondering about the kinda-not-standard key bindings as well?

We're not going to be binding this by default - those keys listed are mostly as examples ☺️

[Don-Vito]

tbh this setup feels... bizarre. But I guess that's the price of backwards compatibility? The "if we add MRU support without tab switcher" is also a slight cause for concern. Also wondering about the kinda-not-standard key bindings as well?

Yes.. this is a price of backward-compatibility between the settings and the commands parameters. I tried to do what we discussed earlier and it was confusing as hell 😊 I mean in the global settings you would have an enum, and here you will have two flags, and the entire resolution logic (aka what happens if default is TabSwitcherMode=Disabled, and here useTabSwitcher=True) would be very non-intuitive.

With this solution it is relatively simple: if you have enum defined in param - it will be used, default otherwise.

Regarding the samples, as Mike said, we are not going to bind them, I put the ones I was using for testing, as an example.

[ghost]

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

Handy links:

• Release Notes
• Store Download

[johnburnett]

This doesn't seem to be working in 1.8.1444.0. See below for repro steps, but it doesn't seem possible to make a config that does this:

• "ctrl+pgdn" always goes to the right (with wrapping)
• "ctrl+pgup" always goes to the left (with wrapping)
• "ctrl+tab" always goes to the previously selected tab in MRU order
• "ctrl+shift+tab" always goes to the next selected tab in MRU order

Steps:

Put this in your config:

{
    "useTabSwitcher": true,
    "actions":
    [
        { "command": "nextTab", "tabSwitcherMode": "inOrder", "keys": "ctrl+pgdn" },
        { "command": "prevTab", "tabSwitcherMode": "inOrder", "keys": "ctrl+pgup" },
        { "command": "nextTab", "tabSwitcherMode": "mru", "keys": "ctrl+tab" },
        { "command": "prevTab", "tabSwitcherMode": "mru", "keys": "ctrl+shift+tab" }
    ]
}

1. Open a terminal
2. Create a tab and rename it "A"
3. Create a tab and rename it "B"
4. Create a tab and rename it "C"
5. Hit "ctrl+pgdn" but don't release "ctrl"

I'd expect to have switched to the next right-most tab from "C" (which is "A" at this point), but instead it switches to "B"
Looking at the tab switcher list (because "ctrl" is still being held), you can see why: Terminal thinks the tab order is "C", "B", "A" for some reason.

6. Release "ctrl"
7. Hit "ctrl+pgup" and don't release "ctrl" again

I'd expect to go to "A" (and you do!), but note the tab switcher order is listed as "B", "C", "A"

8. Release "ctrl"
9. Hit "ctrl+pgdn" and before releasing "ctrl", note the tab switcher order is "A", "B", "C"

You should be on tab "B" at this point with no tab switcher.

10. Hit "ctrl+pgdn" and release "ctrl"

You go to tab "A" instead of "C". Repeating step 10 makes you bounce back and forth between "A" and "B" forever.

Given how all this is currently implemented it seems like the only way to hit the original request would be to either introduce an "adjacent" or "leftright" mode for "tabSwitcherMode", or to consider the current "inOrder" behavior a bug, and change it.

[DHowett]

Huh, you're totally right. No matter what mode is set in the action, it still uses the switcher... even if it's disabled. That's way wrong.

[DHowett]

Wait a moment...

We may have fallen prey to legacy command support.

Take two of these ("and call me in the morning"):

        { "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+pgdn" },
        { "command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+pgup" },

EDIT: Substitute inOrder if you'd like. The key is the nested object to contain the "arguments".

[johnburnett]

Yep, that was it exactly - I didn't realize legacy command support was a thing even. Thanks for the catch!