Add support for focus-pane subcommand
#5464
Labels
Area-Commandline
wt.exe's commandline arguments
Issue-Task
It's a feature request, but it doesn't really need a major design.
Product-Terminal
The new Windows Terminal.
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Comments
ghost
added
Needs-Triage
zadjii-msft
added
Product-Terminal
40 tasks
DHowett-MSFT
removed
the
Needs-Triage
This was referenced May 8, 2020
This was referenced Jun 10, 2020
This was referenced Aug 5, 2020
This was referenced Dec 10, 2020
ghost
pushed a commit
that referenced
this issue
Jan 11, 2021
## Summary of the Pull Request Adds support for the `move-focus` subcommand to `wt.exe`. This subcommand works _exactly_ like `moveFocus(up|down|left|right)`. ## References * Will surely conflict with #8183 * Is goodness even in the world where #5464 exists ## PR Checklist * [x] Closes #6580 * [x] I work here * [x] Tests added/passed * [x] Docs PR: MicrosoftDocs/terminal#209 ## Detailed Description of the Pull Request / Additional comments Bear with me, I wrote this before paternity leave, so code might be a bit stale. Oddly, after startup, this _does not_ leave the focus on the pane you moved to. If you `move-focus` during startup, at the end of startup, we'll still focus a _random_ pane. This is because the terminal still auto-focus a TermControl when it's done with layout. While we'll maintain the active control just fine during the startup, at the end of startup, all the controls will complete layout in a random order. This is no different than the startup right now. `wt sp ; sp ; sp` will focus a random pane at the end. This is left for a future someone to fix This is also subject to #2398 / #4692. Moving in a direction isn't _totally_ reliable currently. `focus-pane -t ID` will certainly be more reliable, but this will work in the meantime? ## Validation Steps Performed Opened probably 100 terminals, confirmed that the layout was always correct. Final focused pane was random, but the layout was right.
mpela81
pushed a commit
to mpela81/terminal
that referenced
this issue
Jan 28, 2021
## Summary of the Pull Request Adds support for the `move-focus` subcommand to `wt.exe`. This subcommand works _exactly_ like `moveFocus(up|down|left|right)`. ## References * Will surely conflict with microsoft#8183 * Is goodness even in the world where microsoft#5464 exists ## PR Checklist * [x] Closes microsoft#6580 * [x] I work here * [x] Tests added/passed * [x] Docs PR: MicrosoftDocs/terminal#209 ## Detailed Description of the Pull Request / Additional comments Bear with me, I wrote this before paternity leave, so code might be a bit stale. Oddly, after startup, this _does not_ leave the focus on the pane you moved to. If you `move-focus` during startup, at the end of startup, we'll still focus a _random_ pane. This is because the terminal still auto-focus a TermControl when it's done with layout. While we'll maintain the active control just fine during the startup, at the end of startup, all the controls will complete layout in a random order. This is no different than the startup right now. `wt sp ; sp ; sp` will focus a random pane at the end. This is left for a future someone to fix This is also subject to microsoft#2398 / microsoft#4692. Moving in a direction isn't _totally_ reliable currently. `focus-pane -t ID` will certainly be more reliable, but this will work in the meantime? ## Validation Steps Performed Opened probably 100 terminals, confirmed that the layout was always correct. Final focused pane was random, but the layout was right.
5 tasks
ghost
pushed a commit
that referenced
this issue
May 21, 2021
## Summary of the Pull Request Adds support for the `focusPane` action, and the `focus-pane` subcommand. These allow the user to focus a pane by it's ID. * `focusPane` accepts an `id`, identifying the id of the pane to focus. * `focus-pane`, `fp` requires the parameter `--target,-t` to ID the pane it's going to focus. ## PR Checklist * [x] Closes #5803 * [x] Closes #5464 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - oh no ## Detailed Description of the Pull Request / Additional comments The ID isn't _totally_ useful right now, since users can't see them. But they're there, and used in-order. This is just slightly more ergonomic for complicated commandlines than `mf up; mf left` ## Validation Steps Performed Tested in command palette Tested a variety of commandlines. `wtd -w 0 mf down ; sp` and `wtd -w 0 fp -t 1 ; sp` gave me special difficulty.
ghost
added
Resolution-Fix-Committed
|
🎉This issue was addressed in #10142, which has now been successfully released as Handy links: |
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From the original spec:
This one's a bit more involved - we'll need to make sure to give every leaf pane a unique ID, and when we move a control to a new pane, make sure to move that instance's ID as well.
We might want to have a GUID->ID mapping for this. With the work over in #5000, we'll probably want to give individual terminal instances unique GUIDs, to track them across windows. Might be easiest to just track which terminal instance is in a particular pane, and then use that GUID to get the pane ID within the window.
The text was updated successfully, but these errors were encountered: