microsoft
Add option to disable the tab switcher popup while keeping tab switcher nextTab semantics
Description of the new feature/enhancement
Having configured "tabSwitcherMode": "mru" I can not find an option to hide the (in my opinion distracting) tab switcher popup.
What I want is just MRU semantics on nextTab (especially when/if #9330 gets fixed) and no UI popup flashing by. If that can be achieved with "tabSwitcherMode": "disabled" that would be preferred.
Proposed technical implementation details (optional)
Assuming the tab switcher is the only way to get MRU semantics when using nextTab, a new configuration key to control visibility of the tab switcher popup, e.g. "showTabSwitcherInterface": true|false (default: true).
Huh, a new option named "mruNoUI" ? That's gonna confuse bunch of people.
I agree it's confusing. Perhaps it's having the nextTab MRU behavior tied to the tab switcher is that is the main issue.
I would love to implement MRU switching without the UI.
However, that's a much harder problem than you might expect. The way our keybindings are currently hooked up, if you were to do a nextTab action in MRU order, without the UI, then we'd have no good way of not updating the MRU stack while pressing the keys. (I'm now realizing this is hard to explain in text).
Basically, as you perform nextTab actions, we'll update the MRU stack. The UI lets us not actually perform the nextTab action until you release all the keys. So while you're using the UI, we're not updating the stack. If there wasn't a UI, then we'd update the stack immediately. So if you have four tabs, [a, b, c, d], and tried to switch from a to b, the stack would now be [b, a, c, d]. The next MRU nextTab would get you a again. So you'd only be able to flip between the two most recent tabs.
Obviously this isn't great, and we want to fix that. That's just the long-winded explanation of why we haven't yet.
Would it be possible to let the tab switcher popup get the focus and handle the keyboard events but keep it invisible? I imagine that might cause surprising effects for accessibility software.
Basically, as you perform nextTab actions, we'll update the MRU stack. The UI lets us not actually perform the nextTab action until you release all the keys. So while you're using the UI, we're not updating the stack. If there wasn't a UI, then we'd update the stack immediately. So if you have four tabs,
[a, b, c, d], and tried to switch fromatob, the stack would now be[b, a, c, d]. The next MRU nextTab would get youaagain. So you'd only be able to flip between the two most recent tabs.Obviously this isn't great, and we want to fix that. That's just the long-winded explanation of why we haven't yet.
Without actually reading the code I think the explanation makes sense. But it feels far from ideal to have the UI work around limitations in the keybinding code.
Thinking a bit more about this, perhaps it's actually the look of UI itself that is the problem for me. Instead of showing a popup how about highlighting the tab (perhaps using the effect as when you hover a tab) that the user would switch to upon release of the hotkey?
I would love to implement MRU switching without the UI.
However, that's a much harder problem than you might expect. The way our keybindings are currently hooked up, if you were to do a
nextTabaction in MRU order, without the UI, then we'd have no good way of not updating the MRU stack while pressing the keys. (I'm now realizing this is hard to explain in text).Basically, as you perform nextTab actions, we'll update the MRU stack. The UI lets us not actually perform the nextTab action until you release all the keys. So while you're using the UI, we're not updating the stack. If there wasn't a UI, then we'd update the stack immediately. So if you have four tabs,
[a, b, c, d], and tried to switch fromatob, the stack would now be[b, a, c, d]. The next MRU nextTab would get youaagain. So you'd only be able to flip between the two most recent tabs.Obviously this isn't great, and we want to fix that. That's just the long-winded explanation of why we haven't yet.
@zadjii-msft - probably we can unify this one with https://github.com/microsoft/terminal/issues/9330. Both have the same theme: decouple between the switch order and if the tab switcher should be visible or not.
@KalleOlaviNiemitalo - I am not sure it is good approach to show invisible palette. We just need to capture anchor in the terminal page.
@zadjii-msft - can we do something like:
- _UpdateMRUTab will do nothing if modifier key is pressed
- KeyUpHandler: if the key is modifier (and there are no modifiers left) and the current tab is not in MRU top, then put it on top Of course thils will work, only if there is an anchor key for tab switching
Meh, I'd almost leave the threads decoupled, just because each thread does have it's own problem it is trying to solve. Like we can add the args to #9390 without fixing the "no UI for MRU switching" issue. They're seemingly converging, but still we could fix this issue before we add the args to next/prevTab, then now we need to find out how to express globally "I want mru tab switching without the UI".
Of course this will work, only if there is an anchor key for tab switching
And that's maybe part of the issue. I feel like I remember someone wanting tab switching on something like F11 & F12.
And that's maybe part of the issue. I feel like I remember someone wanting tab switching on something like F11 & F12.
But this will not work with tab switcher today as well.
But this will not work with tab switcher today as well.
That's a good point. Yea that might work.
_UpdateMRUTab will do nothing if modifier key is pressed KeyUpHandler: if the key is modifier (and there are no modifiers left) and the current tab is not in MRU top, then put it on top Of course thils will work, only if there is an anchor key for tab switching
Have there been any developments on this front?
@M43R the best way to show your support for this issue is by hitting the 👍 button on this issue
That way, you avoid unnecessarily pinging everyone following this thread. Thanks!