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

Feature Request: optional splitting of view into scroll pane and static pane while scrolling #3652

New Issue
Open
opened 2026-01-30 23:26:32 +00:00 by claunia · 3 comments
claunia commented 2026-01-30 23:26:32 +00:00
Owner
Copy Link

Originally created by @tomaswindsor on GitHub (Aug 29, 2019).

While scrolling, it is sometimes useful to see the current output (bottom of the view) at same time and even be able to type commands on prompt while seeing distant content in scrolled view without aborting the scrolling (e.g. to copy from long manual pages). In these situations it would help if (when enabled) scrolling would automatically split the view pane into two panes: static pane and scroll pane. Either with horizontal splitter (then static pane would be the bottom pane and scroll pane would be the upper pane) or vertically (then static pane would be the left pane and scroll pane would be the right pane). Scrolling would only take place in the scroll pane, static pane would always show the bottom lines of the view.

Proportion of the panes should be configurable e.g. by specifying the size of the static pane either in percents or in number of lines. Setting this to 0 or 0% would effectively disable this feature.

The splitter could be moved using drag'n'drop/keybindings as well. If typing on command prompt wouldn't abort scrolling in this mode (this could also be optional), there should be a button and keybinding to abort the scrolling (this abort scrolling command would be effectively same as move-scrollbar-to-bottom command).

The content of the scroll pane shouldn't move with additional content appearing in the terminal to allow user to read/copy the content without disruptions. (only the scrollbar would move in such case to reflect the change of position of the scroll pane in the whole scroll buffer).

Originally created by @tomaswindsor on GitHub (Aug 29, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> While scrolling, it is sometimes useful to see the current output (bottom of the view) at same time and even be able to type commands on prompt while seeing distant content in scrolled view without aborting the scrolling (e.g. to copy from long manual pages). In these situations it would help if (when enabled) scrolling would automatically split the view pane into two panes: static pane and scroll pane. Either with horizontal splitter (then static pane would be the bottom pane and scroll pane would be the upper pane) or vertically (then static pane would be the left pane and scroll pane would be the right pane). Scrolling would only take place in the scroll pane, static pane would always show the bottom lines of the view. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> Proportion of the panes should be configurable e.g. by specifying the size of the static pane either in percents or in number of lines. Setting this to 0 or 0% would effectively disable this feature. The splitter could be moved using drag'n'drop/keybindings as well. If typing on command prompt wouldn't abort scrolling in this mode (this could also be optional), there should be a button and keybinding to abort the scrolling (this abort scrolling command would be effectively same as move-scrollbar-to-bottom command). The content of the scroll pane shouldn't move with additional content appearing in the terminal to allow user to read/copy the content without disruptions. (only the scrollbar would move in such case to reflect the change of position of the scroll pane in the whole scroll buffer). <!-- A clear and concise description of what you want to happen. -->
claunia commented 2026-01-30 23:26:34 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 29, 2019):

I like this idea. It might require some extra technical difficulty - I'm not sure we can build a pair of TermControls that share a single Terminal instance, but it might be possible. The Terminal itself might need some re-working too - currently it only supports a single visible viewport, but there's not reason it couldn't have multiple.

I think the thing I'm having an extra hard time with is how we activate this split pane, and communicate it appropriately.

  • Do we add a keybinding arg (#1142) for splitting not with a particular profile, but instead as a view into the existing terminal?
  • How do we identify that both these panes are the same terminal?
  • What happens when you close the scrolling one or the static one - presumably the remaining one takes over as the primary?
  • How does this interact with other panes? Is there anything special about this type of pane?

This might be better suited as an extension, though, with the Terminal changes we'd need to make, it'd probably require a lot of support internally.

@zadjii-msft commented on GitHub (Aug 29, 2019): I like this idea. It might require some extra technical difficulty - I'm not sure we can build a pair of `TermControl`s that share a single `Terminal` instance, but it might be possible. The `Terminal` itself might need some re-working too - currently it only supports a single visible viewport, but there's not reason it couldn't have multiple. I think the thing I'm having an extra hard time with is _how_ we activate this split pane, and communicate it appropriately. * Do we add a keybinding arg (#1142) for splitting not with a particular profile, but instead as a view into the existing terminal? * How do we identify that both these panes are the _same_ terminal? * What happens when you close the scrolling one or the static one - presumably the remaining one takes over as the primary? * How does this interact with other panes? Is there anything special about this type of pane? This might be better suited as an extension, though, with the `Terminal` changes we'd need to make, it'd probably require a lot of support internally.
claunia commented 2026-01-30 23:26:34 +00:00
Author
Owner
Copy Link

@tomaswindsor commented on GitHub (Aug 29, 2019):

  • What happens when you close the scrolling one or the static one - presumably the remaining one takes over as the primary?

Closing of the scrolling pane will happen even automatically if you scroll to the bottom. So what happens when you close the scrolling pane (when you move the scrollbar to the bottom)? The scrolling pane will disappear and the static pane will be extended to occupy the entire area. If you close the static pane, it should perhaps remove both panes (as the scrolling pane can be seen as a sub-pane of the static one).

  • How does this interact with other panes? Is there anything special about this type of pane?

It is special in a way that every scrolling pane will be tied with up to 1 static pane (0 if this feature is not used and then the normal pane simply becomes scrolling pane during scrolling as it is now).

@tomaswindsor commented on GitHub (Aug 29, 2019): >* What happens when you close the scrolling one or the static one - presumably the remaining one takes over as the primary? Closing of the scrolling pane will happen even automatically if you scroll to the bottom. So what happens when you close the scrolling pane (when you move the scrollbar to the bottom)? The scrolling pane will disappear and the static pane will be extended to occupy the entire area. If you close the static pane, it should perhaps remove both panes (as the scrolling pane can be seen as a sub-pane of the static one). > * How does this interact with other panes? Is there anything special about this type of pane? It is special in a way that every scrolling pane will be tied with up to 1 static pane (0 if this feature is not used and then the normal pane simply becomes scrolling pane during scrolling as it is now).
claunia commented 2026-01-30 23:26:35 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 29, 2019):

This is very related to #644

@zadjii-msft commented on GitHub (Aug 29, 2019): This is very related to #644
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-Extensibility Area-UserInterface Issue-Feature 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#3652
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?