Repository navigation
Support manually clearing the conpty buffer #1193
Description
From Daniel Imms (@Tyriar) in microsoft/vscode#75141
This is happening because Terminal: Clear tells the frontend (the thing rendering everything) to clear, but the way that the conpty backend works is it will sometimes reprint what it thinks should be visible. Since it doesn't know about our clear it reprints the unwanted output, this doesn't happen on a regular linux/mac backend that conpty is trying to emulate.
Is there anything that can be done here to tell conpty to not reprint the screen? I suspect python.exe does not enter alt mode so I'm not sure why a reprint is necessary.
Reacted by Kowalski Dragon, candlends, Escape0707, Vivek M, Andreas Opferkuch, Yegor, Alec Geatches, icetbr, Kristian Dupont, Dan Pike and 4 more
Activity
DHowett-MSFT commentedon Jun 10, 2019
Thoughts: new thing to put on the signal pipe? We don't want to introduce too many non-standard VT things to the in/out pipes, so the signal pipe is our "get out of jail free" card.
Tyriar commentedon Jun 10, 2019
I don't think this is a good idea for that reason.
DHowett-MSFT commentedon Jun 10, 2019
Sorry, I think you'll need to be more specific about what
thisandthat reasonare.Tyriar commentedon Jun 10, 2019
DHowett-MSFT commentedon Jun 11, 2019
So, okay, if I understand this correctly:
You're asking for us to cut this feature request, because you do not believe that we should add support for it; you do, however, still want it to exist?
Tyriar commentedon Jun 11, 2019
I think there's a bug as Mike Griese (@zadjii-msft) indicated in the linked issue that I want fixed instead of adding non-standard stuff to conpty. Setting a variable and printing it in Python should not redraw the entire screen, see microsoft/vscode#75141 (comment) for context.
zadjii-msft commentedon Jun 11, 2019
Well, I think the bug might be making this issue more apparent, but I don't think fixing the bug mentioned will actually properly resolve this issue. It might temporarily hide the issue, by allowing the cursor to start printing text again at the origin. However, the text wouldn't actually be at the origin in conpty's buffer, and it's entirely possible that another action could cause conpty to need to redraw everything - at which point, all the old text would re-appear, and the new text would suddenly shift to where conpty thinks it is.
For *nix, VSCode's terminal clear works just fine because the pty is just a dumb pipe - when you clear the frontend's buffer, there's nothing on the backend that still thinks that there's any text in the buffer, because there is no buffer.
However, with conpty, because there is an actual buffer on the backend, we can't just clear the frontend like that. The conpty buffer will still think something's there. Since this is a problem unique to conpty & windows, I think it's unfortunately something that needs a unique solution.
I'm half way on board with adding another signal to the signal pipe - that'll clearly work unique to Windows, since it'd introduce another API to our API surface. If we want to avoid adding another signal here, we could maybe add the clear by making conpty resond to something like
^[[3Jon the input. However, I know that doing the resize on the input pipe also had some problems with making sure the resize sequence wouldn't be broken up by other input sequences, esp for WSL and docker. Hence the addition of the signal pipe. I think the signal would end up being the safest, most robust solution.I really want to make sure we avoid API creep on the conpty API though. We need to make sure that this is something that's definitely not accomplish-able by some other means.
Tyriar commentedon Jun 11, 2019
Mike Griese (@zadjii-msft) I get that there will be times when it fails just as it will on nix (eg. running clear in the alt buffer) and I'm fine with the Terminal Clear command not working properly in those cases. Fixing the conpty-specific cases doesn't seem worth it since it can happen off with a native pty too.
Isn't conpty meant to be pretending to be a dumb pipe here in the same way as a native pty? I tried doing that same action to run the current Python file on a mac and it will just print a bunch of characters, CR, LF and use the character attribute escape (CSI m). In a similar way it would be lovely if conpty did not reprint the screen when resized unless something actually changed, ie. a line in the viewport is wrapped or will be wrapped.
DHowett-MSFT commentedon Jun 11, 2019
ConPTY is pretending to be as close to a dumb pipe as it can. That's the major contention here: there is a 35-year history of win32 console applications that have access to the output buffer. We cannot be a dumb pipe, because that's not something that fits into the "dumb pipe" model.
Any concessions we've made in what ConPTY can do and does do are in the pursuit of the broadest possible compatibility.
maxhora commentedon Oct 1, 2019
Why not to support 2 modes of ConPTY: plain "dumb pipe" and ConPTY with legacy support for
35-year history of win32 console? :)1 remaining item
yurenchen000 commentedon Nov 11, 2020
it seems that:
clearorclswill clear scroll buffer in PowerShell.clswill clear scroll buffer in CMD.but
clearORresetOR CSI sequence not clear scroll buffer in bash.can we have some workaround to implement buffer clear ?
some thing like,
associate shortcut keys (or something else) to call windows
clearorclsto current "tty". (Bypass the current running bash.exe , ssh.exe..),DHowett commentedon Nov 11, 2020
yurenchen000 Are you using Cygwin, MSYS, or MinGW bash? If so, what version of the runtime are you using? Certain versions of the Cygwin runtime delete CSIs.
Clearing the buffer works fine from bash, so long as the CSI is not deleted.
yurenchen000 commentedon Nov 11, 2020
thanks a lot.
seems
printf "\e[H\e[2J\e[3J"will clear scroll buffer, in some situations (not all).I use lots of cli environment:
"\e[H\e[2J\e[3J")can I ignore the CLI environment,
and have a terminal itself's GUI option (mouse right menu or shortcut key) to clear scroll buffer?
This plumbs #1882 and #1193 all the way through.
zadjii-msft commentedon Jul 29, 2021
Alright, worked on this a bit in
dev/migrie/fhl-2021/clear-buffer-action. Small bits of trickiness:SCREEN_INFORMATION::VtEraseAllis not the thing we'd want to use to do this - that pretty blindly just scrolls away the old buffer contents into scrollback. We could:vim.vim.I mean, this almost certainly will never do the right thing for a full screen app so we may as well do i. because it's easier now.
AdaptDispatchandDispatchCommon. These changes won't be necessary anymore, so better to remove them, and reduce the likelyhood that someone else uses them wrong.DispatchCommon::s_ClearBuffermethod, thatPtySignalInputThread::_DoClearBuffercalls.SCREEN_INFORMATION::VtEraseAll, but with clearing everything above the cursor, and leaving the cursor on the top row of the viewport.vimet al. will definitely do the wrong thing.Implement and action for manually clearing the Terminal (and conpty) …