-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
ConPTY emits nothing to clear the right side when downsizing #8880
Comments
So, for the record, I've been through madness and back trying to get this just right. You might be interested in #4200, and the PRs and issues linked to that one. I have notes scattered throughout. Be aware, this way leads madness.
If that's the end goal, then I think the best plan is to just not decrease the ConPTY size. ConPTY assumes that the end terminal buffer is exactly as large as conpty is. So make conpty exactly as large as you want your buffer. If you want to have your buffer be larger than the viewport, go for it. That's how I'm planning on addressing #1860. Trying to keep external buffers in sync with the console buffer is really annoying, and there's not a good way to do it. The problem comes from the fact that there fundamentally is a buffer that conpty must maintain for the client apps to be able to query, but it must also keep that buffer in sync with the terminal emulator. Unfortunately, the emulator may resize itself while conpty is reacting to a previous resize attempt, and now conpty is trying to render into a space that's different dimensions. WT gets around this by manually telling conpty "I know what I'm doing, don't repaint on a resize", then manually reflowing the WT buffer exactly the same way conhost would. So yeah, good luck 😄 |
my problem is that I don't have a buffer per se, only strings, and the client can emit infinitely (uint32_t) long strings (and use horizontal scrolling or my own wrapping) |
Right, but... having no bounded size is incompatible with terminal emulation. Even when you're hosting processes on Linux, they can request the size in both character cells and pixels with |
The internal structure of my terminal does not have any width limitation. To implement this, I added a new concept to the "viewport" concept: "right oversize" (+ "left oversize" for RTL). Applications that ask the terminal about its size receive a "viewport" in response. The process of stacking text in the terminal takes into account the "oversize". |
ConPTY works as expected if I force the use of What I missed is that ConPTY is updated independently of Windows Terminal. Now I will rely on the compiled |
Environment
I am making my own terminal multiplexer using ConPTY.
ConPTY instances serve as consoles for multiplexer applications. The dimensions of these consoles can be changed by mouse. Each time the console is resized, the ConPTY instance is resized at the same time, which triggers it to redraw its buffer contents.
Using ConPTY in my own terminal emulator, it is impossible to know that visible lines should be truncated when the ConPTY is reduced in size. ConPTY emits nothing to clear the right side when downsizing.
May be related to #5800
Actual behavior
The picture below shows the multiplexer, where the ConPTY consoles are located on the left, and on the right is a window with the output of everything that ConPTY emits when redrawn (top part is raw text, bottom part is code points)
Console lines are doubled in case my built-in terminal wraps the lines by itself:
In the case when my built-in terminal has horizontal scrolling enabled, the lines are simultaneously continued and wrapped (since ConPTY wraps lines):
It looks like ConPTY does not take into account that the external buffer may be larger and there may be fragments left when the ConPTY is reduced in size.
A possible solution would be to add
\e[m\e[K
before\r\n
at the end of each line to indicate that this is an explicit end of the line.CSI Ps K Erase in Line (EL), VT100.
The text was updated successfully, but these errors were encountered: