starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Pane focus movement doesn't remember where it came from #6586

New Issue
Open
opened 2026-01-31 00:42:24 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 00:42:24 +00:00
Owner
Copy Link

Originally created by @keithn on GitHub (Feb 22, 2020).

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

Originally created by @keithn on GitHub (Feb 22, 2020). # 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
claunia commented 2026-01-31 00:42:25 +00:00
Author
Owner
Copy Link

@moswald commented on GitHub (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.

@moswald commented on GitHub (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.
claunia commented 2026-01-31 00:42:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 4, 2021):

Huh. This looks like it's the same thing as #2398, so I'm gonna clean this one out of the backlog. Thanks!

/dup #2398

@zadjii-msft commented on GitHub (Feb 4, 2021): Huh. This looks like it's the same thing as #2398, so I'm gonna clean this one out of the backlog. Thanks! /dup #2398
claunia commented 2026-01-31 00:42:25 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Feb 4, 2021):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Feb 4, 2021): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
claunia commented 2026-01-31 00:42:26 +00:00
Author
Owner
Copy Link

@mg-christian-esser commented on GitHub (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

|----------|
|    |  2  |
|    |_____|
|  1 |  3  |
|    |_____|
|    |  4  |
|____|_____|

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.

@mg-christian-esser commented on GitHub (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 ``` |----------| | | 2 | | |_____| | 1 | 3 | | |_____| | | 4 | |____|_____| ``` 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.
claunia commented 2026-01-31 00:42:26 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (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.

@zadjii-msft commented on GitHub (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.
claunia commented 2026-01-31 00:42:26 +00:00
Author
Owner
Copy Link

@mg-christian-esser commented on GitHub (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.

@mg-christian-esser commented on GitHub (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.
claunia commented 2026-01-31 00:42:26 +00:00
Author
Owner
Copy Link

@Rosefield commented on GitHub (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

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

Where the tree is

  / \
 /\  2
1 /\
  3 4

Right now if you have 4 selected and move right, you'll hit 2. Then, if you move left

  • current behavior selects 1 as focus
  • 2398 will have you select either 3 or 4 since they are the two neighbors of 2, and I believe 3 would be selected since it is the "first-most" neighbor pane.
  • this issue proposes to select from either 3 or 4, preferring 4 because it was more recent in history.
@Rosefield commented on GitHub (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 ``` ------------------------------- | | | | | 1 | 3 | 2 | | |---------| | | | 4 | | ------------------------------- ``` Where the tree is ``` / \ /\ 2 1 /\ 3 4 ``` Right now if you have `4` selected and move right, you'll hit `2`. Then, if you move left - current behavior selects `1` as focus - 2398 will have you select either 3 or 4 since they are the two neighbors of 2, and I believe `3` would be selected since it is the "first-most" neighbor pane. - this issue proposes to select from either 3 or 4, preferring 4 because it was more recent in history.
claunia commented 2026-01-31 00:42:26 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 22, 2021):

this issue proposes to select from either 3 or 4, preferring 4 because it was more recent in history.

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 https://github.com/microsoft/terminal/issues/4692#issuecomment-773268698 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:

|----------------|
|  1  |    |  5  |
|_____|    |_____|
|  2  |  4 |  6  |
|_____|    |_____|
|  3  |    |  7  |
|_____|____|_____|

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.

@zadjii-msft commented on GitHub (Jul 22, 2021): > this issue proposes to select from either 3 or 4, preferring 4 because it was more recent in history. 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 https://github.com/microsoft/terminal/issues/4692#issuecomment-773268698 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: ``` |----------------| | 1 | | 5 | |_____| |_____| | 2 | 4 | 6 | |_____| |_____| | 3 | | 7 | |_____|____|_____| ``` 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.
claunia commented 2026-01-31 00:42:27 +00:00
Author
Owner
Copy Link

@Rosefield commented on GitHub (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.

@Rosefield commented on GitHub (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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Help Wanted Issue-Bug Priority-2 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#6586
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?