Support for navigating panes by MRU

[PankajBhojwani]

Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane

We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.

From our offline discussion (thanks @zadjii-msft for the concise
description):

For the record, the full spec I'm imagining is:

{ command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },

and order defaults to mru, and useSwitcher will default to true, when
there is a switcher. So

{ command": { "action": "focusNextPane" } },
{ command": { "action": "focusNextPane", "order": "mru" } },

these are the same action. (but right now we don't support the order
param)

Then there'll be another PR for "focusPane(target=id)"

Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"

for the record, I prefer this approach over the "one action to rule
them all" version with both target and order/direction as params,
because I don't like the confusion of what happens if there's both
target and order/direction provided.

References #1000
Closes #2871

[carlos-zamora]

A few other things:

• Don't forget to update the docs/schema
• what happens if we provide "next" or "previous" to "resizePane"?

[PankajBhojwani]

what happens if we provide "next" or "previous" to "resizePane"?

The _Resize() function will return false and nothing happens. I've noted in the docs that the direction given to resize cannot be next or previous. If people feel strongly about it we can make them two distinct direction enums?

[carlos-zamora]

The _Resize() function will return false and nothing happens. I've noted in the docs that the direction given to resize cannot be next or previous. If people feel strongly about it we can make them two distinct direction enums?

A few issues here:

1. Generally, when you put an invalid value for the arg in the json, we display a warning.
2. When you say "nothing happens" does it eat the keybinding or does the keybinding still get sent to the buffer (i.e. ^A)?
3. Right now, we have enum mappers exposing enums to the Settings UI. Though keybindings aren't there yet, we'll probably use this the same way. If we have a single enum mapper for Direction, we'll have to figure out how to exclude "next" and "previous" in one keybinding arg, but not the other.

I'd rather you split the enum into 2 different ones in the schema and the code. It just acts more properly that way and it's more future-proof.

[PankajBhojwani]

I'd rather you split the enum into 2 different ones in the schema and the code. It just acts more properly that way and it's more future-proof.

Fair enough, its split now!

[carlos-zamora]

Thank you. You could keep the ResizeDirection as just plain Direction if you wanted to reduce the diff. But I'm fine either way.

[zadjii-msft]

Okay my immediate thoughts are around how we expose this action to the user. We're already running into similar struggles with next/prevTab and the tab switcher, so maybe we should try and pre-empt those issues with pane switching?

For reference, there's also discussion in #8025 that might be helpful.

So, with next/prev MRU switching, without some sort of dialog, those will just toggle between the last two used panes. If there's a fourth pane, that pane will be inaccessible with next/prev pane.

Also, having panes in the ATS is something we might want some day, with something like:

• Tab 1:
  • Pane 1: cmd.exe
  • Pane 2: pwsh.exe
• Tab 2:
  • Pane 1: wsl.exe

whatever, you get it.

Plus, do we want to enable in-order next/prev traversal? Once we have pane IDs, then presumably, yea.

---

Do we want to overload moveFocus to accept next and prev, or would having another action entirely be better? Here are some proposals:

// Focus pane 1
// - This is sensible, no arguments here
{ command": { "action": "focusPane", "id": 1 } },

// Focus the next in order pane, don't use the switcher
// - We'd have to ensure that an id and order aren't passed at the same time, and that might be unintuitive
// - How do we specify next/prev? "direction" seems wrong, but maybe we keep the
//   FocusDirection(up|down|left|right|next|prev) enum and have one focus action 
//   to rule them all
{ command": { "action": "focusPane", "order": "inOrder", useSwitcher": false } },

// Focus the next MRU pane
// - Withough the switcher, this can only go one pane deep in the MRU stack
// - presumably once there's a pane switcher, it would default to enabled?
{ command": { "action": "focusNextPane", "order": "mru" } },

// Focus the prev inOrder pane
// - this seems straightforward
{ command": { "action": "focusPrevPane", "order": "inOrder" } },

// Focus the next pane, in mru order, explicitly disable the switcher
// - The user opted in to only being able to MRU switch one deep. That's fine, that's what they want.
{ command": { "action": "focusNextPane", "order": "mru", "useSwitcher": false} },

// Focus the prev inOrder pane, explicitly with the switcher
// - Maybe they disabled the switcher globally, but what it on for this action? 
{ command": { "action": "focusPrevPane", "order": "inOrder", "useSwitcher": true } },

Thoughts?

[zadjii-msft]

@msftbot make sure @zadjii-msft signs off on this

[ghost]

Hello @zadjii-msft!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

• I'll only merge this pull request if it's approved by @zadjii-msft

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".

[PankajBhojwani]

I like the idea of having separate commands for focusPrevPane and focusNextPane in preparation for the pane switcher.

Plus, do we want to enable in-order next/prev traversal? Once we have pane IDs, then presumably, yea.

I am not sure about this, we will need a way for the user to know the pane IDs and that may not always be feasible - paging @DHowett for thoughts on this

[carlos-zamora]

Do we want to overload moveFocus to accept next and prev, or would having another action entirely be better? Here are some proposals:

@zadjii-msft @PankajBhojwani Could we create a spec for this and discuss the design in a brownbag? There seems to be a lot of options here. And I'd like to make sure the design interacts well with the current ATS customization model. Especially given our recent experience with ATS MRU.

[DHowett]

I don’t think this requires a spec. An informal chat should do!

[cinnamon-msft]

Is { command": { "action": "focusPrevPane", "order": "inOrder" } }, in order of creation or in order from left-right, top-bottom? Also does this order change once we get pane rearrangement?

[ghost]

Hello @zadjii-msft!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

• I won't merge this pull request until after the UTC date Fri, 04 Dec 2020 23:12:51 GMT, which is in 19 hours

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".

[zadjii-msft]

I think I follow all this, and it looks good to me. I'm telling the bot to wait until EOD Friday to merge this, to give Dustin one last chance, but I think this is fine

[zadjii-msft]

wait did we want the setting to be previous or prev? It's prevTab and nextTab now,

But you know what I'm totally okay with this.

[DHowett]

Hit this with a code format!

[ghost]

Hello @DHowett!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.