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 · 56 comments

Comments

Projects
None yet
@andersk
Member

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

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk Feb 20, 2012

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Feb 27, 2012

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@chingjun

chingjun 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.

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

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 16, 2012

Member

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).

Member

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

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk Apr 16, 2012

Member

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.
Member

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

This comment has been minimized.

Show comment
Hide comment
@scottgifford

scottgifford 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!

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

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 23, 2012

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@taralx

taralx Apr 23, 2012

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

taralx commented Apr 23, 2012

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

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 23, 2012

Member

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

Member

keithw commented Apr 23, 2012

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

@NickWoodhams

This comment has been minimized.

Show comment
Hide comment
@NickWoodhams

NickWoodhams Jun 6, 2012

Agreed. This is the only significant issue with Mosh at the moment. It's the only issue that has tainted my experience.

NickWoodhams commented Jun 6, 2012

Agreed. This is the only significant issue with Mosh at the moment. It's the only issue that has tainted my experience.

@haarts

This comment has been minimized.

Show comment
Hide comment
@haarts

haarts commented Jun 11, 2012

+1

@lucasprim

This comment has been minimized.

Show comment
Hide comment
@lucasprim

lucasprim commented Jun 19, 2012

+1

@davidjao

This comment has been minimized.

Show comment
Hide comment
@davidjao

davidjao Mar 10, 2013

Thanks everyone, the --no-init option works perfectly to disable alternate screen mode for those of us who don't want it.

In the spirit of keeping the documentation up to date, could we mention in the man page (in the ENVIRONMENT VARIABLES section) that the MOSH_NO_TERM_INIT variable inhibits smcup/rmcup?

davidjao commented Mar 10, 2013

Thanks everyone, the --no-init option works perfectly to disable alternate screen mode for those of us who don't want it.

In the spirit of keeping the documentation up to date, could we mention in the man page (in the ENVIRONMENT VARIABLES section) that the MOSH_NO_TERM_INIT variable inhibits smcup/rmcup?

@simonbcn

This comment has been minimized.

Show comment
Hide comment
@simonbcn

simonbcn Aug 16, 2013

For me the "--no-init" option doesn't resolve the scrollback problem with mouse wheel.

simonbcn commented Aug 16, 2013

For me the "--no-init" option doesn't resolve the scrollback problem with mouse wheel.

@pitrou

This comment has been minimized.

Show comment
Hide comment
@pitrou

pitrou Sep 14, 2013

"--no-init" is completely broken here with the XFCE terminal: some part of the output is forgotten in history, and the scrollbar gets updated inconsistently. Why can't mosh just behave as ssh does? Being opinionated is fine, but it would also be nice to benefit from the networking improvements without having different terminal emulation decisions forced on the user.

pitrou commented Sep 14, 2013

"--no-init" is completely broken here with the XFCE terminal: some part of the output is forgotten in history, and the scrollbar gets updated inconsistently. Why can't mosh just behave as ssh does? Being opinionated is fine, but it would also be nice to benefit from the networking improvements without having different terminal emulation decisions forced on the user.

@dtenenba

This comment has been minimized.

Show comment
Hide comment
@dtenenba

dtenenba Dec 13, 2013

The

mosh user@host -- screen -dR 

workaround works. What would be the equivalent command for using tmux instead of screen and ensuring no tmux processes are left behind when I disconnect?

Thanks.

dtenenba commented Dec 13, 2013

The

mosh user@host -- screen -dR 

workaround works. What would be the equivalent command for using tmux instead of screen and ensuring no tmux processes are left behind when I disconnect?

Thanks.

@dtenenba

This comment has been minimized.

Show comment
Hide comment
@dtenenba

dtenenba Dec 13, 2013

Actually I spoke too soon. The screen workaround has issues. If I use it in two separate terminal windows, one after the other, the second window hijacks the screen in the first window. Would be great to have scrollback to eliminate the need for this. Thanks.

dtenenba commented Dec 13, 2013

Actually I spoke too soon. The screen workaround has issues. If I use it in two separate terminal windows, one after the other, the second window hijacks the screen in the first window. Would be great to have scrollback to eliminate the need for this. Thanks.

@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk Dec 14, 2013

Member

@dtenenba, this is not a support forum for tmux and screen. Read the manpages (tmux(1), screen(1)), especially the parts about the -d option to tmux attach-session, and the -d, -r, -x options to screen.

Member

andersk commented Dec 14, 2013

@dtenenba, this is not a support forum for tmux and screen. Read the manpages (tmux(1), screen(1)), especially the parts about the -d option to tmux attach-session, and the -d, -r, -x options to screen.

@azag0

This comment has been minimized.

Show comment
Hide comment
@azag0

azag0 Oct 3, 2014

I would like to call this article into attention. It describes a nice simple setup combining mosh and tmuc resulting in a working scrollback history (with mouse) on terminals supporting xterm mouse. On OS X, that's iTerm or even Terminal.app with easySIMBL and MouseTerm plugin.

azag0 commented Oct 3, 2014

I would like to call this article into attention. It describes a nice simple setup combining mosh and tmuc resulting in a working scrollback history (with mouse) on terminals supporting xterm mouse. On OS X, that's iTerm or even Terminal.app with easySIMBL and MouseTerm plugin.

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Dec 15, 2014

It seems this is still not really implemented? Running mosh -n --no-init still disables scrolling for me? (Mac OS X with Terminal.)

mitar commented Dec 15, 2014

It seems this is still not really implemented? Running mosh -n --no-init still disables scrolling for me? (Mac OS X with Terminal.)

@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk Dec 15, 2014

Member

--no-init only exists to restore the pre-1.2.4 behavior of not disabling the terminal’s scroll bar, to appease those who believed that functionality was being lost. Mosh has never been able to guarantee that the terminal’s scroll buffer will actually be filled with anything, much less anything useful, because of the way it optimizes frame deltas in its state synchronization protocol. See #122.

Member

andersk commented Dec 15, 2014

--no-init only exists to restore the pre-1.2.4 behavior of not disabling the terminal’s scroll bar, to appease those who believed that functionality was being lost. Mosh has never been able to guarantee that the terminal’s scroll buffer will actually be filled with anything, much less anything useful, because of the way it optimizes frame deltas in its state synchronization protocol. See #122.

@emschorsch

This comment has been minimized.

Show comment
Hide comment
@emschorsch

emschorsch Oct 2, 2015

It would be really nice if mosh supported scrollback. I'm using mysql on the server and Describe's output is longer than the screen so it's impossible for me to see the top. Oh well, back to ssh I guess.

emschorsch commented Oct 2, 2015

It would be really nice if mosh supported scrollback. I'm using mysql on the server and Describe's output is longer than the screen so it's impossible for me to see the top. Oh well, back to ssh I guess.

@tsuna

This comment has been minimized.

Show comment
Hide comment
@tsuna

tsuna Oct 3, 2015

In the mysql cli you can just do pager less and the output will be redirected to less instead of being printed directly.

tsuna commented Oct 3, 2015

In the mysql cli you can just do pager less and the output will be redirected to less instead of being printed directly.

@emschorsch

This comment has been minimized.

Show comment
Hide comment
@emschorsch

emschorsch Oct 5, 2015

@tsuna Thank you! That command is awesome

emschorsch commented Oct 5, 2015

@tsuna Thank you! That command is awesome

cgull added a commit to cgull/mosh that referenced this issue Oct 5, 2015

andreub pushed a commit to andreub/mosh that referenced this issue Jun 17, 2016

Merge pull request #2 from jkraemer/agent-forwarding-merge-20151128-b…
…uild_fix

build fix for the agent forwarding branch

cgull added a commit to cgull/mosh that referenced this issue Mar 18, 2017

@cordovapolymer

This comment has been minimized.

Show comment
Hide comment
@cordovapolymer

cordovapolymer Apr 6, 2017

any hope that this will be fixed someday?

cordovapolymer commented Apr 6, 2017

any hope that this will be fixed someday?

@edbergavera

This comment has been minimized.

Show comment
Hide comment
@edbergavera

edbergavera Jul 5, 2017

The --no-init flag sometimes works sometimes doesn't. We are hoping to see a native scrollback support with Mosh.

Latest iTerm2 on macOS Sierra 10.12.5

edbergavera commented Jul 5, 2017

The --no-init flag sometimes works sometimes doesn't. We are hoping to see a native scrollback support with Mosh.

Latest iTerm2 on macOS Sierra 10.12.5

@Khalian

This comment has been minimized.

Show comment
Hide comment
@Khalian

Khalian Aug 11, 2017

Yea this is a pretty big deal for me. I will use this once this obvious showstopper is fixed.

Khalian commented Aug 11, 2017

Yea this is a pretty big deal for me. I will use this once this obvious showstopper is fixed.

@dragon788

This comment has been minimized.

Show comment
Hide comment
@dragon788

dragon788 Oct 20, 2017

Really not sure what all the fuss is about, if you want scrollback use screen or tmux, they are wonderful tools, and using them appropriately will let you do SO much more than trying bolt more features into mosh. The unix philosophy for tools, do one thing well, is PERFECTLY illustrated in this case. https://en.wikipedia.org/wiki/Unix_philosophy

I just tested this on my local machine connecting to another machine. I connect using mosh, reconnect to tmux using -- tmux attach as the argument of the connection string, and I'm reconnected to my session with the ability to scroll back through history, scroll my tmux "window bar" to go to different panes, in short everything that people have been asking for above WITHOUT any changes to mosh.

If you are scrolling back through previous commands you are probably using only mosh or you are in screen. It does this whether you connect via SSH or mosh, because it uses the "alternate screen" itself. I like screen, but tmux is much better for multiple commands and sessions, and handles scrolling and history in a far more sane manner in my opinion.

dragon788 commented Oct 20, 2017

Really not sure what all the fuss is about, if you want scrollback use screen or tmux, they are wonderful tools, and using them appropriately will let you do SO much more than trying bolt more features into mosh. The unix philosophy for tools, do one thing well, is PERFECTLY illustrated in this case. https://en.wikipedia.org/wiki/Unix_philosophy

I just tested this on my local machine connecting to another machine. I connect using mosh, reconnect to tmux using -- tmux attach as the argument of the connection string, and I'm reconnected to my session with the ability to scroll back through history, scroll my tmux "window bar" to go to different panes, in short everything that people have been asking for above WITHOUT any changes to mosh.

If you are scrolling back through previous commands you are probably using only mosh or you are in screen. It does this whether you connect via SSH or mosh, because it uses the "alternate screen" itself. I like screen, but tmux is much better for multiple commands and sessions, and handles scrolling and history in a far more sane manner in my opinion.

@edbergavera

This comment has been minimized.

Show comment
Hide comment
@edbergavera

edbergavera Oct 20, 2017

edbergavera commented Oct 20, 2017

@davidjao

This comment has been minimized.

Show comment
Hide comment
@davidjao

davidjao 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.

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

This comment has been minimized.

Show comment
Hide comment
@dragon788

dragon788 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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment