Repository navigation
Pane focus movement doesn't remember where it came from #4692
Description
Steps to reproduce
create a vertical split, then on the right pane, create a horizontal split
somewhat like this :
|-----------|
| | 2 |
| 1 |______|
| | 3 |
|____|______|
if you move focus from 1 to 2 by moveFocus right
then move focus from 2 to 3 by moveFocus down
then move focus from 3 to 1 by moveFocus left
then moveFocus right
Expected behavior
The focus should go back to 3. Otherwise toggling between 1 and 3 becomes a painful, especially if 2 is ends up more complicated with more panes.
Actual behavior
focus goes to 2
Reacted by Christian Esser, Arvind and Václav Brožík
Reacted by Christian Esser
Activity
[-]Focus movement doesn't remember where it came from[/-][+]Pane focus movement doesn't remember where it came from[/+]moswald commentedon Feb 27, 2020
Agreed. Movement between panes should be MRU, rather than through move left/right/up/down which is ambiguous in a lot of cases.
Add a `move-focus` subcommand (#8546)
Add a `move-focus` subcommand (microsoft#8546)
5 remaining items
mg-christian-esser commentedon Feb 4, 2021
I'd say there's a subtle, non-compatible difference between this and #2398. In this ticket the user want to remember focus in a multicolumn layout while in #2398 the user want to rely on visual alignment.
To clarify this ticket, if the layout was a bit more complicated like
And we moved from 3 and move left to 1 then if we move right again we should end up at 3. In #2398 if we rely upon visual alignment we should probably choose 2 or 4 (or maybe even 3).
In my opinion behavior in this ticket makes more sense than #2398 but comes down to user preference. In an ideal world perhaps we do both and let the user decide.
zadjii-msft commentedon Feb 4, 2021
Ooooh. Okay. That's a great layout test case. Yea, I'll reopen this, to make sure we do this as well. Thanks!
IMO we should just do this always. In the "move right from 1" case, I don't think any one of 2, 3, or 4 is the obvious right one to pick. There's a good case for each of them. But moving to the most recent one - now that makes a lot of sense.
mg-christian-esser commentedon Feb 4, 2021
Great to hear! There's of course a similar case with up/down when you have the tiling rotated 90 degrees. I haven't thought much about it and am not sure exactly how the two interact.
Rosefield commentedon Jul 19, 2021
I would argue that this issue and #2398 are complimentary. #2398 defines how to find "neighbor" panes (visually) and this issue gives one possible strategy from selecting from those neighbor panes. Of course there is a dedicated command for
move focus to the last used pane(which may not have existed when this issue was created.)Consider the following case
Where the tree is
Right now if you have
4selected and move right, you'll hit2. Then, if you move left1as focus3would be selected since it is the "first-most" neighbor pane.zadjii-msft commentedon Jul 22, 2021
I'd reckon that 4 is the correct pane to chose between the two. Both seem like reasonable choices, but I'd bet that it's more likely that someone wants to return to where they came from rather than just "the first one". Especially if we consider the #4692 (comment) example. Say the user moved from 4->1, then tried moving right again. They probably don't want to go to 4.
To get more complicated:
2->4->{right}->4->{left} should probably end on 2 again, since it was the MRU of [1, 2, 3].
That being said, we can probably do #2398, then do this in a follow-up when there's a "tie" between multiple panes.
Update NavigateFocus function to use new visual-based navigation (#10756
Rosefield commentedon Aug 17, 2021
If/when this gets implemented, I think it would be nice if it could be controlled by setting to enable/disable it.