Feature Request: Add nextPane and prevPane keybindings

[moswald]

There's nextTab and prevTab, but since I work in a single-tab, multi-pane environment, those keybindings do nothing for me. How about being able to bind ctrl+tab to nextPanel?

(Would fit in nicely with the rest of #1000 .)

Edit: I can't believe I typoed that last nextPanel as nextTab, making the sentence and request completely nonsensical. :D

[zadjii-msft]

As of #1910, you can move the focus between panes "directionally", with moveFocus{Up|Down|Left|Right}.

For example:

            { "keys": ["alt+left"], "command": "moveFocusLeft" },
            { "keys": ["alt+right"], "command": "moveFocusRight" },
            { "keys": ["alt+up"], "command": "moveFocusUp" },
            { "keys": ["alt+down"], "command": "moveFocusDown" },

I suppose though there's also room for moving focus "in order" or "in MRU order" through panes as well. MRU order makes sense, but I'm not really sure how "in order" would work

I'm going to leave this open because this makes sense as a potential feature, though I believe that #1910 will probably satisfy your needs.

[moswald]

Yeah, I'm using the current moveFocus bindings, but they're just not as natural as the ctrl+tab muscle memory I've built up using other apps. I usually switch between just two tabs so MRU would work great, but "in order" could be implemented by remembering the order in which tabs were created.

[DHowett-MSFT]

Yanking the triage tag on this one, since it's a worthwhile thing we should probably have. "Backlog" status stays!

[zadjii-msft]

From @mfeiertag in #7194

New panes get assigned increasing IDs.
{ "command": { "action": "moveFocus", "direction": "next" }, "keys": "ctrl+alt+tab" }
focuses the pane with the next ID
{ "command": { "action": "moveFocus", "direction": "prev" }, "keys": "ctrl+alt+shift+tab" }
focuses the pane with the previous ID

IDs could be in order of creation or in order of last used.
Property Necessity Type Default Description
paneCycleMode Optional String created Defines the order of panes when cycling. Possible values: created or lastUsed

Related to #5803 and #5464
Similar to #4692

Example (pane in focus bold):

Single Pane:
| 1 |
Duplicate pane:
| 1 | | 2 |
Pressing ctrl+alt+tab:
| 1 | | 2 |
Duplicate Pane 1, than pane 2:
| 1 | | 2 |
| 3 | | 4 |
Pressing ctrl+alt+tab would go to pane 1:
| 1 | | 2 |
| 3 | | 4 |
Pressing ctrl+alt+shift+tab would go back to pane 4:
| 1 | | 2 |
| 3 | | 4 |
Pressing ctrl+alt+shift+tab again would go to pane 3:
| 1 | | 2 |
| 3 | | 4 |

[DHowett]

moveFocus with direction: previous will be how you do this.

[Rosefield]

This item seems incomplete, specifically the next portion is missing from the current implementation and the linked spec. To me the idea of having the "in order" style cycling is important (equivalent to just cyclically alt-tabbing between panes) that lets me get to any pane through one keybinding. The "in order" order can be fairly arbitrary (so long as it is consistent), but just iterating through the tree leaves from first-leaf to last-leaf seems reasonable.

Also, the current implementation of the previous movement seems tangential to the "in order backwards" version, in that it only cycles between two panes. e.g. if you have 3 panes, 1| 2 | 3, and you go from 2 to 3, pressing previous will go to 2, then pressing previous will go back to 3 again, with no way to go back to 1. This can be separately useful, but seems to be solving a different feature request.

I would be happy to implement the "in order" next/previous version, but I'm not sure if that goes against the grand plan.

[zadjii-msft]

You know, that's a fair point. We never did come up with an in-order traversal method - that was seemingly lost part of the discussion. I think we got so focused on the MRU previous element, the in-order bit was lost.

I'll bring this up in team sync. See what other folks think. Thanks for bringing this up!

[zadjii-msft]

After discussion, yea, we totally forgot about the inOrder version of this. "moveFocus": "nextInOrder" and "moveFocus": "previousInOrder" seemed like they were likely candidates for the param to mean "take me to ++paneId" / "take me to --paneId".

I'll move this to a new issue. Thanks for keeping us honest!