ConPTY: pass through requests for the alt buffer #381
Comments
|
They're processed inside the console host window (which is hosting cmd.exe and powering your ConPTY session) to establish and remove an alternate screen buffer at that level. The effects of the operation will be visible on the output pipe (that is, it should "clear the screen" and then draw the contents of the alternate one onto the final terminal attached to the ConPTY end). But the final terminal isn't responsible for the maintenence of that state right now. I believe that tools like Internally we have the potential future work item to make it so there is a ConPTY "pass-through" mode. MSFT: 20190846. |
miniksa
added
backlog
Product-Conpty
|
Indeed tools such as
It would be really nice if the console window behaved like Centos in this case, as I find it much more intuitive and a convenient way to read documents. Furthermore, terminal emulators with their own scrollback function are unable to provide the Centos-like behavior if they are not aware that the alternate buffer has been opened. The pass-through mode sounds like it'd make it possible for terminal emulators to handle this themselves, thanks! (Happy to provide some gifs if I've done a poor job explaining the behavior?) |
|
Unfortunately conpty doesn't support mouse input quite yet, though that's something fairly high on our backlog. Pass-throughing the alt buffer switching is something that we'll likely do earlier than adding mouse support, and definitely before enabling a true passthrough mode. |
|
Sounds great, thanks! |
DHowett-MSFT
changed the title
|
Hi @DHowett-MSFT, |
|
@ihor-sviziev every bug that we keep open is something we are hoping to fix :) we have been prioritizing other things because we wanted to make sure the basic experience worked properly. This one is more complicated because it needs to work for classic Win32 applications at the same time as modern VT applications (like the ones running inside WSL!) |
|
@DHowett-MSFT maybe there is a way to support it only for WSL as first part and later on add support for for win32 applications? |
|
It’s something we could consider, but if the solution to making it work for WSL wouldn’t be something we could build on for Win32, I’d rather not ask my team to do the throwaway work. Once the pressure from 1.0 lets up, we’ll be able to evaluate things like this 😄 |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
The rendering settings will neither fix nor break this. If you observed them helping, that was just a stroke of luck. 😄 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This PR allows the Terminal to actually use the alt buffer
appropriately. Currently, we just render the alt buffer state into the
main buffer and that is wild. It means things like `vim` will let the
user scroll up to see the previous history (which it shouldn't).
Very first thing this PR does: updates the
`{Trigger|Invalidate}Circling` methods to instead be
`{Trigger|Invalidate}Flush(bool circling)`. We need this so that when an
app requests the alt buffer in conpty, we can immediately flush the
frame before asking the Terminal side to switch to the other buffer. The
`Circling` methods was a great place to do this, but we don't actually
want to set the circled flag in VtRenderer when that happens just for a
flush.
The Terminal's implementation is a little different than conhost's.
Conhost's implementation grew organically, so I had it straight up
create an entire new screen buffer for the alt buffer. The Terminal
doesn't need all that! All we need to do is have a separate `TextBuffer`
for the alt buffer contents. This makes other parts easier as well - we
don't really need to do anything with the `_mutableViewport` in the alt
buffer, because it's always in the same place. So, we can just leave it
alone and when we come back to the main buffer, there it is. Helper
methods have been updated to account for this.
* [x] Closes #381
* [x] Closes #3492
* #3686, #3082, #3321, #3493 are all good follow-ups here.
ghost
added
Resolution-Fix-Committed
|
🎉This issue was addressed in #12561, which has now been successfully released as Handy links: |
When running cmd.exe inside a pseudoconsole, trying to enter the alternate screen buffer escape sequences via
echo �[?1049handecho �[?1049ldoes not result in them being sent to the ConPTY output pipe. It appears to me they are being processed inside cmd.exe and swallowed.Does it make sense / is it possible for these sequences be output by ConPTY? This would allow terminal emulators to do things like support scrolling inside programs such as
lesswhich make use of the alternate screen buffer.The text was updated successfully, but these errors were encountered: