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

Scrollback and alternate screen (was: Use alternate screen on smcup/rmcup ) #2

Closed
andersk opened this issue Oct 13, 2011 · 81 comments
Closed
Labels
Milestone

Comments

@andersk
Copy link
Member

@andersk andersk commented Oct 13, 2011

When the remote application uses smcup to enter the alternate screen, the client should put the real terminal in alternate screen mode too, so that for example the mouse wheel lets you scroll in less and emacs and barnowl.

@andersk
Copy link
Member Author

@andersk andersk commented Feb 20, 2012

Or perhaps the client should always put the real terminal in alternate screen mode, for much the same reason that curses applications do—the scrollback history it generates in the primary screen isn’t particularly useful anyway.

@keithw
Copy link
Member

@keithw keithw commented Feb 27, 2012

In normal use (like line-by-line typing at the shell), the real-terminal scrollback will be somewhat useful. I'm not sure I want to give that up completely, although maybe the user would be annoyed that larger prints are only there partially in the scrollback.

@chingjun
Copy link

@chingjun chingjun commented Apr 11, 2012

Hi, I would like to know if you have any plan on this issue? I think mosh should work just like ssh, that it will enter smcup mode when the remote application requests so. I find it quite annoying when I use vim to open a large file and it leaves a lot of scrollbacks.

@keithw
Copy link
Member

@keithw keithw commented Apr 16, 2012

Here is the current proposed solution:

(a) mosh-client puts the terminal in the alternate screen for the whole time

(b) mosh-server interprets SMCUP/RMCUP the way xterm does, so people's "vim" continues to work the same as in xterm (or in screen with altscreen enabled)

(c) we grab control-pgUp and control-PgDown for our own devious ends (providing proper scrollback).

@andersk
Copy link
Member Author

@andersk andersk commented Apr 16, 2012

Sounds reasonable to me. I proposed the following modifications to (c):

  • we also grab Ctrl-Up and Ctrl-Down (since this is what Ctrl-wheel sends in gnome-terminal)
  • but we don’t grab any keys for scrollback while the inner application is inside an alternate screen.
@scottgifford
Copy link

@scottgifford scottgifford commented Apr 23, 2012

Do I understand correctly that the plan here is to provide scrollback similar to what a regular terminal provides? That is, if I run a command with a lot of output, I can reliably scroll back with my terminal's scrollbars to see everything that was output by that command? That is a really important usability issue for me. Thanks!

@keithw
Copy link
Member

@keithw keithw commented Apr 23, 2012

Yes, Scott, that's the plan, although you won't be able to use your local terminal's scroll bars. For now you can use screen or tmux on the server side to get this feature.

@taralx
Copy link

@taralx taralx commented Apr 23, 2012

This is a cool idea. Is it possible to support mousewheel too?

@keithw
Copy link
Member

@keithw keithw commented Apr 23, 2012

Yes, if we do it with Anders's amendment, it will support the mouse wheel.

@NickWoodhams

This comment was marked as spam.

@haarts

This comment was marked as spam.

1 similar comment
@lucasprim

This comment was marked as spam.

@dragon788

This comment was marked as off-topic.

@edbergavera

This comment was marked as off-topic.

@davidjao
Copy link

@davidjao davidjao commented Oct 20, 2017

The fuss has nothing to do with lack of scrollback functionality. The fuss is that in alternate screen mode, mouse wheel events destroy the current command buffer because a mouse wheel event is interpreted as an arrow key. This is devastating because it means accidental scrolling leads to data loss.

Your suggestion seems to be "don't use GNU screen" but this advice is untenable for many obvious reasons.

@dragon788
Copy link

@dragon788 dragon788 commented Dec 21, 2017

@edbergavera I'm scrolling back using the tmux history via copy-mode (which preserves the command output on the remote, which IMO since it is where the commands are running and where it really matters is where the history should be). I believe you can use the mouse scroll wheel if you have a plugin for tmux that interprets the scroll wheel escape codes as a signal to enter copy mode and scroll, or you can simply Prefix+[ or whatever you bind to enter copy mode and then scroll with your mouse assuming your terminal isn't capturing the events and forwards them to the server intact. Prefix+Esc is another equivalent.

@mobile-shell mobile-shell deleted a comment from jjarava Dec 10, 2018
@martininsulander
Copy link

@martininsulander martininsulander commented Feb 14, 2019

What about a flag telling how much history to load at start (like tail -n)?

@JohanMollevik

This comment was marked as spam.

@rjurney

This comment was marked as spam.

@mr-propre

This comment was marked as spam.

@rjurney

This comment was marked as spam.

@defaultxr
Copy link

@defaultxr defaultxr commented Aug 13, 2019

Not sure if it was mentioned here already, but if you're affected by this issue you may want to take a look at Eternal Terminal as an alternative.

@keithw
Copy link
Member

@keithw keithw commented Aug 13, 2019

Folks -- you realize you can adjust the amount of scrollback that screen and tmux save?

This is a solved problem for most people (who are using screen/tmux, or even less, on the server side). Mosh is probably not getting its own remote-scrollback protocol anytime soon.

@rjurney

This comment was marked as spam.

@deed02392

This comment was marked as spam.

@jjarava

This comment was marked as spam.

@eminence
Copy link
Member

@eminence eminence commented Sep 6, 2019

Most of the same mosh benefits still apply when using tmux:

  • Seamless connectivity when your client changes networks or your client machine comes out of a suspended/hibernated state
  • local echo
  • better control-C handling
@rjurney

This comment was marked as off-topic.

@comex
Copy link

@comex comex commented Oct 1, 2019

Myself, I don't object to using tmux, but scrolling using tmux is laggy as it requires waiting for the remote server to send the updated screen contents. One of Mosh's core selling points is that it provides better interactivity than ssh on slow or unreliable networks. However, when it comes to scrollback, relying on tmux provides worse interactivity than local scrollback.

@rjurney
Copy link

@rjurney rjurney commented Oct 1, 2019

How hard would it be to add a rollback to mosh? What is involved?

@eminence
Copy link
Member

@eminence eminence commented Oct 2, 2019

but scrolling using tmux is laggy as it requires waiting for the remote server to send the updated screen contents

If mosh ever learns how to do scrollback, I'm imaging that it would have to do the same thing, so I don't quite understand this complaint.

@comex
Copy link

@comex comex commented Oct 3, 2019

Why would it have to do the same thing? In principle Mosh should be able to keep a local copy of the scrollback buffer. I suppose there might be issues if something is spamming the terminal fast enough that the client doesn't receive all the text (since Mosh intentionally throttles screen updates to a fixed framerate). But that's solvable; Mosh would need some sort of algorithm to sync scrollback contents with the server, ideally with a lower priority than screen updates.

@caruccio

This comment was marked as off-topic.

@habibalamin

This comment was marked as off-topic.

@rjurney

This comment was marked as off-topic.

@rjurney

This comment was marked as off-topic.

@andersk
Copy link
Member Author

@andersk andersk commented Feb 27, 2020

Let’s bring this conversation back down from low Earth orbit, guys. The reason Mosh doesn’t support scrollback has nothing to do with philosophy. It also has nothing to do with whether this ticket is open or closed—there’s already a ticket open for scrollback, and it’s not this ticket, which was about alternate screen mode. It has everything to do with limited developer time. If you’ve read the Mosh paper, you’ll understand how the way Mosh prioritizes interactivity makes delivering usable scrollback a challenge, so it was left out of the initial implementation and nobody has had time to add it since. If we had infinite time to work on Mosh, a scrollback feature would likely be a priority. Nobody is stopping you from developing this functionality if you are interested, and as always, a well-designed, well-implemented pull request is likely to be accepted. But complaining on a closed issue isn’t going to make that happen any faster.

@JohanMollevik

This comment was marked as off-topic.

@habibalamin

This comment was marked as off-topic.

@eminence
Copy link
Member

@eminence eminence commented Feb 28, 2020

I am going to unlock the open issue about scrollback, since it's had a chance to cool off. However, please avoid commenting on that issue (or this issue) if there is nothing new to add. There are "reaction" buttons in github that can be used to express your interest (which don't spam the whole thread), and comments like "+1" aren't useful. We know this is a very important issue to some people and that running screen/tmux on the server isn't always a convenient or acceptable solution.

Comments about unix philosophy are interesting, but are definitely off-topic for this github issue tracker. (However, you're welcome to join our #mosh IRC channel on freenode to discuss such things).

@geohuz

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.