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

Re-draw issue on resize #1265

Open
aytey opened this issue Oct 25, 2021 · 2 comments
Open

Re-draw issue on resize #1265

aytey opened this issue Oct 25, 2021 · 2 comments
Labels
bug Something isn't working Windows Issue applies to Microsoft Windows

Comments

@aytey
Copy link
Contributor

aytey commented Oct 25, 2021

What Operating System(s) are you seeing this problem on?

Windows

WezTerm version

wezterm 20211024-192045-f4ee31fe

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Using local build from main @ f4ee31f

Describe the bug

While writing-up #1263 I noticed that I have some "redraw" issues after resizing.

Step 1:

  • Start with a file cat'd to the screen and in full screen

image

Step 2:

  • Shrink the window to whatever the default size is

image

Step 3:

  • Maximise the window

image

So there are two issues here:

  1. It would be great if maximised -> shrunk -> maximised left what was on the screen alone (i.e., if I have a full screen of text before shrinking, and then I shrink/remaximise, it should have the same screen as before)
  2. The cursor is "floating" in the middle of nowhere (I think it is at its position in the "shrunk" window size)

To Reproduce

  • cat a large file to the screen when the window is maximised
  • shrink the window
  • maximise the window again

Configuration

no config

Expected Behavior

It would be great if maximised -> shrunk -> maximised left what was on the screen alone

Logs

No response

Anything else?

No response

@aytey aytey added the bug Something isn't working label Oct 25, 2021
@wez wez added the Windows Issue applies to Microsoft Windows label Jan 17, 2022
@davidrios
Copy link
Contributor

I have this same issue. Something very similar also happens in Windows Terminal, and since this problem doesn't appear in other platforms, I thinks it's likely an issue with ConPTY.

wez added a commit that referenced this issue Mar 30, 2022
Previously, we'd just default the resize quirk on for all programs on
Windows.

That pessimizes the otherwise fine behavior of `wezterm ssh` or mux
connections to unixy platforms.

This commit moves the quirk out of the config trait and makes it
a runtime property of the terminal, and then arranges for it
to be set when we know that we set up a conpty for the terminal.

refs: #1265
@wez
Copy link
Owner

wez commented Mar 30, 2022

There's a lot of bugs around resizing in conpty:

The most problematic aspect of it is that the cursor moves up and then conpty decides to repaint the screen at that position, corrupting the output.

wezterm has a quirk mode for conpty to push the screen contents into the scrollback as part of resizing, in order to preserve the existing output, but it is still frustrating to deal with the fallout as the cursor position doesn't seem to agree in all cases.

I think we're waiting for this to land in conpty to bypass that layer:

I've learned to live with this when working in pwsh or cmd, but try to avoid conpty when I'm working in a unix environment by using either wezterm ssh or wezterm connect to bypass conpty and talk directly to the unix pty implementation.

I just pushed 53c4714 to disable the resize quirk mode for those bypass cases: previously it was hard coded to enabled for the windows GUI. Now it is only enabled when we know that we started ConPTY for a given pane.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Windows Issue applies to Microsoft Windows
Projects
None yet
Development

No branches or pull requests

3 participants