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

Single line scrolling fails in mux-server, if application uses alternate screen mode #6166

Open
loops opened this issue Sep 20, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@loops
Copy link
Contributor

loops commented Sep 20, 2024

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:

 $ unset LESS

Now generate lines, and press ENTER multiple times in less to scroll screen:

  $ seq 1 1000 | less

Another way to see the is to use this script (which works fine unless going through mux):

 $ tput smcup ; tput clear cup $(tput lines) ; for i in $(seq 1 20) ; do echo $i ; sleep 0.1; done

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

@loops loops added the bug Something isn't working label Sep 20, 2024
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
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant