Repository navigation
Feature Request: Add nextPane and prevPane keybindings #2871
Description
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
Reacted by Andrew Baumann, Giorgio Acquati, David Dyball, Maxime Deloche and mean-street
Activity
zadjii-msft commentedon Sep 24, 2019
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 commentedon Sep 24, 2019
Yeah, I'm using the current
moveFocusbindings, but they're just not as natural as thectrl+tabmuscle 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 commentedon Oct 7, 2019
Yanking the triage tag on this one, since it's a worthwhile thing we should probably have. "Backlog" status stays!
zadjii-msft commentedon Aug 5, 2020
From mfeiertag in #7194
1 remaining item
Support for navigating panes by MRU (#8183)
DHowett commentedon Dec 11, 2020
moveFocuswithdirection: previouswill be how you do this.Add a spec for pane navigation (#8375)
Support for navigating panes by MRU (microsoft#8183)
Add a spec for pane navigation (microsoft#8375)
Rosefield commentedon Jul 29, 2021
This item seems incomplete, specifically the
nextportion 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
previousmovement 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 commentedon Aug 3, 2021
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 commentedon Aug 9, 2021
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!