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
Comments
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 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 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 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. |
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 |
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:
That's what made me think that only one layer would need to be visible at a time. I may be misreading that though.
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. |
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. |
I'm gonna convert this to "Support VT paging API's", and generally keep the "layers" thing over in #10810. Thanks for the discussion! |
NP
, PP
, PPA
)
This PR adds support for multiples pages in the VT architecture, along with new operations for moving between those pages: `NP` (Next Page), `PP` (Preceding Page), `PPA` (Page Position Absolute), `PPR` (Page Position Relative), and `PPB` (Page Position Back). There's also a new mode, `DECPCCM` (Page Cursor Coupling Mode), which determines whether or not the active page is also the visible page, and a new query sequence, `DECRQDE` (Request Displayed Extent), which can be used to query the visible page. ## References and Relevant Issues When combined with `DECCRA` (Copy Rectangular Area), which can copy between pages, you can layer content on top of existing output, and still restore the original data afterwards. So this could serve as an alternative solution to #10810. ## Detailed Description of the Pull Request / Additional comments On the original DEC terminals that supported paging, you couldn't have both paging and scrollback at the same time - only the one or the other. But modern terminals typically allow both, so we support that too. The way it works, the currently visible page will be attached to the scrollback, and any content that scrolls off the top will thus be saved. But the background pages will not have scrollback, so their content is lost if it scrolls off the top. And when the screen is resized, only the visible page will be reflowed. Background pages are not affected by a resize until they become active. At that point they just receive the traditional style of resize, where the content is clipped or padded to match the new dimensions. I'm not sure this is the best way to handle resizing, but we can always consider other approaches once people have had a chance to try it out. ## Validation Steps Performed I've added some unit tests covering the new operations, and also done a lot of manual testing. Closes #13892 Tests added/passed
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:
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.
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.
The text was updated successfully, but these errors were encountered: