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

Add support for the VT Paging APIs (NP, PP, PPA) #18346

New Issue
Closed
opened 2026-01-31 06:11:06 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 06:11:06 +00:00
Owner
Copy Link

Originally created by @JamesKehr on GitHub (Aug 31, 2022).

Description of the new feature/enhancement

This request is for multi-layer support in a terminal. This would be used for CLI-based wizards, menus, tools (think htop), etc. without disturbing the root command line.

This is not panes or tabs, which open additional terminal processes. Each layer in the terminal would be part of the same command line process. It would be like using layers in a photo/drawing editor, but with CLI.

Example:

  1. PowerShell starts in the default layer (layer 0). This is just the normal terminal.

image

  1. A multi-layer aware wizard/menu/tool could then request a new layer from the runspace.
    a. This would be layer X (i.e. layer 1 if run from the root/default layer).
    b. The wizard/menu/tool would run in layer 1.
    c. Layer 1 would be a separate thread in the same process where the console/terminal is running. Like a ThreadJob…or something along those lines.
    d. While the wizard is running the user only sees Layer 1, while Layer 0 lurks inactive/deactivated in the background.

image

  1. The wizard completes, Layer 1 is closed, returning any objects needed back to layer 0 in the process.
  2. User continues in Layer 0 (default), right where they left off. The default console is undisturbed by the wizard.

Proposed technical implementation details (optional)

I have no idea how this would work. I only know it would be awesome 😊

I assume that PowerShell would need to know about layers to use them. I would assume changes to both PowerShell and terminal are needed. Or maybe not, if PowerShell can do all of this virtually.

If each layer is just a text buffer that's swapped in and out of the process that displays terminal/console to the user then it could be cross-platform, cross-terminal/console. Maybe… I don't know for sure. Just a thought.

Originally created by @JamesKehr on GitHub (Aug 31, 2022). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 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! --> # Description of the new feature/enhancement This request is for multi-layer support in a terminal. This would be used for CLI-based wizards, menus, tools (think htop), etc. without disturbing the root command line. This is not panes or tabs, which open additional terminal processes. Each layer in the terminal would be part of the same command line process. It would be like using layers in a photo/drawing editor, but with CLI. Example: 1. PowerShell starts in the default layer (layer 0). This is just the normal terminal. ![image](https://user-images.githubusercontent.com/40303902/187776461-1d10474f-4906-4059-83d1-57febe917838.png) 2. A multi-layer aware wizard/menu/tool could then request a new layer from the runspace. a. This would be layer X (i.e. layer 1 if run from the root/default layer). b. The wizard/menu/tool would run in layer 1. c. Layer 1 would be a separate thread in the same process where the console/terminal is running. Like a ThreadJob…or something along those lines. d. While the wizard is running the user only sees Layer 1, while Layer 0 lurks inactive/deactivated in the background. ![image](https://user-images.githubusercontent.com/40303902/187777716-af0e16c8-0d94-4026-8348-99c433216b0c.png) 3. The wizard completes, Layer 1 is closed, returning any objects needed back to layer 0 in the process. 4. User continues in Layer 0 (default), right where they left off. The default console is undisturbed by the wizard. <!-- 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). --> # Proposed technical implementation details (optional) I have no idea how this would work. I only know it would be awesome 😊 I assume that PowerShell would need to know about layers to use them. I would assume changes to both PowerShell and terminal are needed. Or maybe not, if PowerShell can do all of this virtually. If each layer is just a text buffer that's swapped in and out of the process that displays terminal/console to the user then it could be cross-platform, cross-terminal/console. Maybe… I don't know for sure. Just a thought. <!-- A clear and concise description of what you want to happen. -->
claunia commented 2026-01-31 06:11:08 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 31, 2022):

You know, this is pretty close to what we were discussing in the neighborhood of https://github.com/microsoft/terminal/issues/10810#issuecomment-1163127364. Does that thread (and maybe the few comments before that, maybe start here: https://github.com/microsoft/terminal/issues/10810#issuecomment-897905318) sound like what you were looking for/?

@zadjii-msft commented on GitHub (Aug 31, 2022): You know, this is pretty close to what we were discussing in the neighborhood of https://github.com/microsoft/terminal/issues/10810#issuecomment-1163127364. Does that thread (and maybe the few comments before that, maybe start here: https://github.com/microsoft/terminal/issues/10810#issuecomment-897905318) sound like what you were looking for/?
claunia commented 2026-01-31 06:11:08 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Sep 1, 2022):

@zadjii-msft I think this particular request is simpler than that (if I've understood it correctly), because the layers are completely independent of each other. You could already achieve something like this in the old console using the screen buffer APIs (see CreateConsoleScreenBuffer).

The idea I had, which I think I've mentioned before, was for us to replicate that functionality in Windows Terminal using the VT paging APIs, which are similar in nature (see NP, PP, PPA, etc.). You couldn't "create" new buffers as such, but the terminal would have a predefined number of pages that would be available for use, and you would just move to a new page whenever you needed a new layer/buffer.

Technically we could probably even allow for an infinite number of pages, creating them on demand whenever an app tried to move to a page that hadn't previously been used.

This wouldn't solve #10810, but I think it might be good enough for the OPs multi-layer idea, and it has the advantage of not needing to invent proprietary escape sequences.

@j4james commented on GitHub (Sep 1, 2022): @zadjii-msft I think this particular request is simpler than that (if I've understood it correctly), because the layers are completely independent of each other. You could already achieve something like this in the old console using the screen buffer APIs (see [`CreateConsoleScreenBuffer`](https://docs.microsoft.com/en-us/windows/console/createconsolescreenbuffer#remarks)). The idea I had, which I think I've mentioned before, was for us to replicate that functionality in Windows Terminal using the VT paging APIs, which are similar in nature (see [`NP`](https://www.vt100.net/docs/vt510-rm/NP.html), [`PP`](https://www.vt100.net/docs/vt510-rm/PP.html), [`PPA`](https://www.vt100.net/docs/vt510-rm/PPA.html), etc.). You couldn't "create" new buffers as such, but the terminal would have a predefined number of pages that would be available for use, and you would just move to a new page whenever you needed a new layer/buffer. Technically we could probably even allow for an infinite number of pages, creating them on demand whenever an app tried to move to a page that hadn't previously been used. This wouldn't solve #10810, but I think it might be good enough for the OPs multi-layer idea, and it has the advantage of not needing to invent proprietary escape sequences.
claunia commented 2026-01-31 06:11:08 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 2, 2022):

Huh. I don't think I've ever actually seen those sequences in use. They sure do seem like they've got some overlap here. Do pages "layer" on top of one another? Or are they just... additional buffers? Are there any other emulators which support these out there we can use for reference? I shockingly don't see it on invisible-island

@zadjii-msft commented on GitHub (Sep 2, 2022): Huh. I don't think I've ever actually seen those sequences in use. They sure do seem like they've got some overlap here. Do pages "layer" on top of one another? Or are they just... additional buffers? Are there any other emulators which support these out there we can use for reference? I shockingly don't see it on invisible-island
claunia commented 2026-01-31 06:11:09 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Sep 2, 2022):

Do pages "layer" on top of one another? Or are they just... additional buffers?

They're just additional buffers as far as I understand them. That's why I thought they could probably serve as a reasonable representation of the console buffers.

But if the idea behind this issue was to layer the buffers in a way that the "lower" layers would be visible through the unwritten portions of the "upper" layers, then VT pages would not be suitable. But note point 2d in the description above:

the user only sees Layer 1, while Layer 0 lurks inactive/deactivated in the background.

That's what made me think that only one layer would need to be visible at a time. I may be misreading that though.

Are there any other emulators which support these out there we can use for reference?

The ones that I'm aware of are VTStar, Reflection Desktop, MLTerm, RLogin, and PowerTerm. I haven't done much testing on them, though - I just have notes indicating that they all have some level of paging support.

@j4james commented on GitHub (Sep 2, 2022): > Do pages "layer" on top of one another? Or are they just... additional buffers? They're just additional buffers as far as I understand them. That's why I thought they could probably serve as a reasonable representation of the console buffers. But if the idea behind this issue was to layer the buffers in a way that the "lower" layers would be visible through the unwritten portions of the "upper" layers, then VT pages would not be suitable. But note point 2d in the description above: > the user only sees Layer 1, while Layer 0 lurks inactive/deactivated in the background. That's what made me think that only one layer would need to be visible at a time. I may be misreading that though. > Are there any other emulators which support these out there we can use for reference? The ones that I'm aware of are VTStar, Reflection Desktop, MLTerm, RLogin, and PowerTerm. I haven't done much testing on them, though - I just have notes indicating that they all have some level of paging support.
claunia commented 2026-01-31 06:11:09 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 7, 2022):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Sep 7, 2022): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.
claunia commented 2026-01-31 06:11:09 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 9, 2022):

I'm gonna convert this to "Support VT paging API's", and generally keep the "layers" thing over in #10810. Thanks for the discussion!

@zadjii-msft commented on GitHub (Sep 9, 2022): I'm gonna convert this to "Support VT paging API's", and generally keep the "layers" thing over in #10810. Thanks for the discussion!
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-VT Help Wanted In-PR Issue-Task Needs-Tag-Fix Product-Conhost 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#18346
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?