Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
JamesKehr opened this issue Aug 31, 2022 · 6 comments · May be fixed by #16615
Open

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

JamesKehr opened this issue Aug 31, 2022 · 6 comments · May be fixed by #16615
Labels
Area-VT Virtual Terminal sequence support Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Task It's a feature request, but it doesn't really need a major design. Product-Conhost For issues in the Console codebase Product-Terminal The new Windows Terminal.
Milestone

Comments

@JamesKehr
Copy link

JamesKehr commented 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.

@JamesKehr JamesKehr added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Aug 31, 2022
@zadjii-msft
Copy link
Member

You know, this is pretty close to what we were discussing in the neighborhood of #10810 (comment). Does that thread (and maybe the few comments before that, maybe start here: #10810 (comment)) sound like what you were looking for/?

@zadjii-msft zadjii-msft added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 31, 2022
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Aug 31, 2022
@j4james
Copy link
Collaborator

j4james commented 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.

@zadjii-msft
Copy link
Member

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

@j4james
Copy link
Collaborator

j4james commented 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.

@ghost ghost added the No-Recent-Activity This issue/PR is going stale and may be auto-closed without further activity. label Sep 7, 2022
@ghost
Copy link

ghost commented 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 ghost removed the No-Recent-Activity This issue/PR is going stale and may be auto-closed without further activity. label Sep 7, 2022
@zadjii-msft
Copy link
Member

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 zadjii-msft added Product-Conhost For issues in the Console codebase Help Wanted We encourage anyone to jump in on these. Area-VT Virtual Terminal sequence support Product-Terminal The new Windows Terminal. Issue-Task It's a feature request, but it doesn't really need a major design. and removed Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something Needs-Tag-Fix Doesn't match tag requirements labels Sep 9, 2022
@zadjii-msft zadjii-msft changed the title Add multi-layer support Add support for the VT Paging APIs (NP, PP, PPA) Sep 9, 2022
@zadjii-msft zadjii-msft added this to the Backlog milestone Sep 9, 2022
@j4james j4james linked a pull request Jan 29, 2024 that will close this issue
2 tasks
@microsoft-github-policy-service microsoft-github-policy-service bot added the In-PR This issue has a related PR label Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-VT Virtual Terminal sequence support Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Task It's a feature request, but it doesn't really need a major design. Product-Conhost For issues in the Console codebase Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants