-
-
Notifications
You must be signed in to change notification settings - Fork 797
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
Single line scrolling fails in mux-server, if application uses alternate screen mode #6166
Labels
bug
Something isn't working
Comments
loops
added a commit
to loops/wezterm
that referenced
this issue
Sep 20, 2024
When scrolling in alternate mode, there is no scrollback buffer, which means that every line will actually move, and thus needs to be invalidated. This only caused a problem for the mux-server case, since in the local case all lines are redrawn regardless. Fixed wez#6166
loops
added a commit
to loops/wezterm
that referenced
this issue
Sep 20, 2024
When scrolling in alternate mode, there is no scrollback buffer, which means that every line will actually move, and thus needs to be invalidated. This only caused a problem for the mux-server case, since in the local case all lines are redrawn regardless. Fixes wez#6166
loops
added a commit
to loops/wezterm
that referenced
this issue
Sep 21, 2024
When scrolling in alternate mode, there is no scrollback buffer, which means that every line will actually move, and thus needs to be invalidated. This only caused a problem for the mux-server case, since in the local case all lines are redrawn regardless. Fixes wez#6166
loops
added a commit
to loops/wezterm
that referenced
this issue
Sep 21, 2024
When scrolling in alternate mode, there is no scrollback buffer, which means that every line will actually move, and thus needs to be invalidated. This only caused a problem for the mux-server case, since in the local case all lines are redrawn regardless. Fixes wez#6166
loops
added a commit
to loops/wezterm
that referenced
this issue
Sep 21, 2024
When scrolling in alternate mode, there is no scrollback buffer, which means that every line will actually move, and thus needs to be invalidated. This only caused a problem for the mux-server case, since in the local case all lines are redrawn regardless. Fixes wez#6166
loops
added a commit
to loops/wezterm
that referenced
this issue
Sep 24, 2024
The alternate-screen mode disables scrollback. This means that we delete lines off of the top of the screen when scrolling, without saving them. But we weren't keeping a count of those lines, which meant a stable index was lost; leaving the mux-server unable to properly track scrolling. Now we keep track of the stable_row_index_offset, even when there is no scrollback. This turns out to be the exact same logic as when scrollback is enabled, but after "erase_scrollback" has been called. In both cases, stable_row_index_offset is used to count the number of scrollback-lines, that don't exist in the buffer. As per issue wez#6166
loops
added a commit
to loops/wezterm
that referenced
this issue
Sep 25, 2024
The alternate-screen mode disables scrollback. This means that we delete lines off of the top of the screen when scrolling, without saving them. But we weren't keeping a count of those lines, which meant a stable index was lost; leaving the mux-server unable to properly track scrolling. Now we keep track of the stable_row_index_offset, even when there is no scrollback. This turns out to be the exact same logic as when scrollback is enabled, but after "erase_scrollback" has been called. In both cases, stable_row_index_offset is used to count the number of scrollback-lines, that don't exist in the buffer. As per issue wez#6166
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
Sway
WezTerm version
20240915-082426-9bf30b8d
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
When connected to a Unix or Ssh mux-server, attempting to scroll the screen, when an application has initialized the alternate-screen mode, only the bottom two lines appear to scroll, rather than the full screen.
To Reproduce
The most common place to see this would be in "less" (as long as the -X option is not used):
Make sure -X not used:
Now generate lines, and press ENTER multiple times in less to scroll screen:
Another way to see the is to use this script (which works fine unless going through mux):
As an aside, the above script works fine if you remove the sleep.
Configuration
no config
Expected Behavior
No response
Logs
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: