GH10909 in order movement

[Rosefield]

Adds new in-order traversal for MoveFocus and SwapPane actions.
Refactors the Pane methods to share a NavigateDirection
implementation.

Closes #10909

A large amount of the churn here is just renaming some of the things for
directional movement to reflect that it might not always be based on the
focused pane. NextPane and PreviousPane are the functions that
actually select the next/previous pane respectively and are the core
component of this PR.

VALIDATION
Created multiple panes on a tab, and tried both forward and backwards
movements with move-focus and swap-pane.

[zadjii-msft]

Okay the code is great here. I also talked myself into the idea of doing it in the structural order like this, and left my notes behind for future readers.

Thanks for doing this!

[zadjii-msft]

oh yea, that make way more sense. I like this.

[zadjii-msft]

Oh interesting. So you've got this implemented as "in structural order" navigation. I suppose I imagined this as in "in id order navigation".

So for example:

EXAMPLE A:

 +-------------+        
 | +---+ +---+ |        
 | |   | |   | |        
 | | 1 | | 3 | |        
 | |   | |   | |        
 | +---+ +---+ |        
 +-------------+        
 | +---+ +---+ |        
 | |   | |   | |        
 | | 2 | | 4 | |        
 | |   | |   | |        
 | +---+ +---+ |        
 +-------------+

structural order: [<- 1 <-> 3 <-> 2 <-> 4 ->]

EXAMPLE B:

 +-------+-------+
 | +---+ | +---+ |
 | |   | | |   | |
 | | 1 | | | 3 | |
 | |   | | |   | |
 | +---+ | +---+ |
 | +---+ | +---+ |
 | |   | | |   | |
 | | 2 | | | 4 | |
 | |   | | |   | |
 | +---+ | +---+ |
 +-------+-------+

structural order: [<- 1 <-> 2 <-> 3 <-> 4 ->]

Hmm. Maybe structural makes more sense. Cause in the case where we've got some panes that are opened and closed and opened, the ID order might be insane. Consider example B, close 3&4, then make a new vertical split (5), then close 2, then open a new split off 5 (6), then make a new split off 1 (7)

 +-------+-------+
 | +---+ | +---+ |
 | |   | | |   | |
 | | 1 | | | 5 | |
 | |   | | |   | |
 | +---+ | +---+ |
 | +---+ | +---+ |
 | |   | | |   | |
 | | 7 | | | 6 | |
 | |   | | |   | |
 | +---+ | +---+ |
 +-------+-------+

Now the structural order is: [<- 1 <-> 7 <-> 5 <-> 6 ->] which makes way more sense than [<- 1 <-> 5 <-> 6 <-> 7 ->]

[zadjii-msft]

and honestly structural might make more sense even for the simple case. Esp consider that Example B0 above isn't even truly correct - that assumes the user did a swapPane(2, 3) already! The primary split is vertical, so the layout originally looks like

  +-------+-------+
  | +---+ | +---+ |
  | |   | | |   | |
  | | 1 | | | 2 | |
  | |   | | |   | |
  | +---+ | +---+ |
  | +---+ | +---+ |
  | |   | | |   | |
  | | 3 | | | 4 | |
  | |   | | |   | |
  | +---+ | +---+ |
  +-------+-------+

and here, 1 <-> 3 <-> 2 <-> 4 does seem more reasonable.

[zadjii-msft]

though, I suppose tmux does this with select-pane -t +/-/!:

     target-pane (or src-pane or dst-pane) may be a pane ID or takes a
     similar form to target-window but with the optional addition of a
     period followed by a pane index or pane ID, for example:
     ‘mysession:mywindow.1’.  If the pane index is omitted, the
     currently active pane in the specified window is used.  The
     following special tokens are available for the pane index:

     Token                  Meaning
     {last}            !    The last (previously active) pane
     {next}            +    The next pane by number
     {previous}        -    The previous pane by number
     ...

THOUGH, for tmux, the pane location always stays the same, they just move the content. So doing a swap-pane -s 2 -t 0 will only move the content between 0 and 2, not actually move the id's themselves.

That would mean that the ID order in tmux is always the same as the structural order.

[Rosefield]

Well I'm glad you convinced yourself :). I chose structural order, as you noticed, specifically because the ID order isn't stable and I thought it would be confusing to have the focus move "randomly."

[Rosefield]

I just look forward to when you get a feature request where someone wants custom navigation and you have to implement user-specified continuations to support it ;)

[Rosefield]

Anything that I missed that needs to be discussed, or just want to talk about the structural vs id movement more?

[zadjii-msft]

Sorry I mostly wanted to just draw the team's attention to it. They like it. I think it's getting more reviews now.

[miniksa]

I like it. And I like the structural order. @zadjii-msft explained this one to us in team sync today. The only thing we were left wanting was some visual way (in the future) for us to make the structural order more apparent/visible to the user.

And maybe a more stable ordering/numbering of the panes.

But otherwise, good for now.

[Rosefield]

As for showing the structure, I agree that would be nice and is one of the things I was imagining (but maybe didn't fully explain) in #10733

As for the numbering, there is a bit of a dichotomy between the number/id of the pane itself, and the id of the content of the pane. When chaining commands it makes sense to keep the ID the same, that way I can say "swap panes 2 and 3, then zoom pane 2" (or something) and not have to do the mental calculus of which pane has which id. Over long periods of time or when it is not obvious what the IDs are, having something like #10708 would be helpful, too.

[miniksa]

As for showing the structure, I agree that would be nice and is one of the things I was imagining (but maybe didn't fully explain) in #10733

As for the numbering, there is a bit of a dichotomy between the number/id of the pane itself, and the id of the content of the pane. When chaining commands it makes sense to keep the ID the same, that way I can say "swap panes 2 and 3, then zoom pane 2" (or something) and not have to do the mental calculus of which pane has which id. Over long periods of time or when it is not obvious what the IDs are, having something like #10708 would be helpful, too.

Makes sense to me. Thanks!

[miniksa]

@msftbot merge this in 4 hours

[ghost]

Hello @miniksa!

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 Tue, 17 Aug 2021 02:17:43 GMT, which is in 4 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".

[DHowett]

@msftbot merge this in 1 minute

[ghost]

Hello @DHowett!

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 Mon, 16 Aug 2021 22:31:40 GMT, which is in 1 minute

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

[Rosefield]

@zadjii-msft Since I don't have a better place to post this, I don't really have anything else that I am planning on doing at the moment so I don't know how much I'll be looking at issues. If there happens to be bugs with any of my code feel free to ping me and I can take a look at resolving it.

[miniksa]

I'm sure that's fine @Rosefield. Thank you for this particular contribution!

[ghost]

🎉Windows Terminal Preview v1.11.2421.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download