mosh prevents the use of scrollback

[taralx]

If I use mosh to connect, and then run a command with a lot of output, e.g. ps, my scrollback buffer doesn't get any of the overflow. This is sad-making -- I don't always know when a command will produce a lot of output, and, additionally, I like scrollback for seeing previous commands' output.

[avatar-lavventura]

@RipperSK The root cause of not able to scroll is caused by mosh entering a "alternative screen" mode. It can be disabled using the --no-init flag (see the doc). Just alias mosh='mosh --no-init' and the problem will go away.

@marty1885 I want to use mouse-wheel in emacs and also scrollback in the terminal history.

When I do mosh --no-init I can scrollback in the terminal history but I cannot use mouse wheel in the emacs. Instead if I do only mosh without --no-init flag I can use mouse-scroll in emacs but cannot scroll back in the terminal history. I get lost how can I fix this.

In mosh is it possible to scrollback in the terminal history along with using mouse wheel in emacs, nano, less?

[marty1885]

@eminence Seeing all the comment and feature requests. I think mosh might want to look into implementing it. IMO most people just want a ssh alternative that automatically reconnects after a outage. A broken/terminal with some extra text is still far better than a dead ssh session. I'm not savvy enough to write it. If you think it's worth a try.. May you point me in a direction? I'm sure there's a way since ssh does it.

@avatar-lavventura I did some test. And it seems that smcpu and rmcup sequences used by emacs doesn't work under mosh with --no-init. But vim scrolling still works. You might want to submit a feature request to emacs?

[avatar-lavventura]

Hm on my end it does not work in nano, less, vim, vi :-( I mean it scrolls back in the terminal history but it does not scroll down inside the less or any other editor like emacs.

For example, in ssh, when I do less file, scroll up will go to highest point in the opened file, but with mosh --no-init it goes to top point of the terminal history.

=> Does it work in less or nano on your end?

---

I'm sure there's a way since ssh does it. // If there is a way, I believe it would be very useful feature.

[eminence]

Hi all, I am marking the above comments as "off topic". I want to reiterate a few things:

• I don't consider using --no-init as a way to get reliable access to a local scrollback buffer. You can of course use this option if you understand that it does and its limitations, but if you're having problems with --no-init, this issue is not the place to discuss those issues. Please open a new issue, or find us on IRC to chat
• We definitely know that people want this feature, it's one of the most requested features. But just because ssh is designed in a way to support a local scrollback doesn't mean that mosh can make use of this. I know we've left this issue open for many years, and this might have signaled that we intend to implement this feature. But please interpret this open issue as simply an acknowledgement of the request. We do not have any intention on implementing this feature
• This issue likely has hundreds of subscribers. Please think very carefully before commenting -- does the comment/question you are about to add substantially contribute to the conversation? If not, please open a new issue with your question.

Thanks all

[avatar-lavventura]

@eminence The issue was open since 2012, which is around 10 years ago and I believe it is abandoned. If it is implemented it was implemented by now. There is not hundreds of subscribers in this thread there is only 77. Does your comment contributed for a solution? Using tmux or screen also does not provide a solution for this.

I am not having issue with --no-init, I am having issue with mosh related to mosh prevents the use of scrollback #122 , which does not support scroll back in terminal history along within tools like emacs, nano, vim, vi, less, more and so on. If a developer switching from ssh to mosh there is no way he/she can adapt the scroll behavior of mosh. Without having both together like ssh does, there is no meaning to use mosh at all.

• https://github.com/mobile-shell/mosh/issues/1110
• https://stackoverflow.com/questions/63616612/in-mosh-how-to-scrollback-in-the-terminal-and-use-mouse-in-emacs-less-etc

[FFAMax]

Use case: After working from location with a high speed Internet took the laptop and moved to bus. What changed? Right, connectivity: from stable and high speed to -> unstable and sometimes low speed. Therefore, if we talk not about ignoring all these comments but about hearing and follow to the initial logic of mosh, I see we need another mode. Mode which will determine behaviours. If we can pass all data to client (high speed and stable connection) - why not do that? If mosh detected connection got jitter/delays/losses then -> switch to legacy mode. If connection restored -> switch to high performance mode. Also may be useful with additional options like --mode-hybrid if users really want use this feature. Because I see variants when people may wanna save unneeded traffic even with a stable connection (for example in airplane, roaming, etc).

btw: tmux is another - this require exchange with a remote side. Example: I worked from workplace with a stable connection, had same scroll buffer, after jumped to the bus - if scroll buffer not on my local terminal, it will relay on network reachability instead of to be available locally. :)

[achernya]

Unfortunately the problem here is not network communication, but rather mosh's construction of being a terminal emulator. Native scrollback requires not just a reliable channel, but also not being a full terminal emulator.

This issue is marked as a feature request and remains open in the mosh bug tracker slated for some future milestone. This means that the mosh team has an interest in working on this, but is not committing to a timeline for its completion.

To folks that are interested in this feature: we're interested in proposals to fix this and PRs to do so, but please don't comment on this issue attempting to motivate the use case further. Rest assured that you've been heard -- feel free to 👍 up the top comment to express your support.

[eternaleye]

Native scrollback requires not just a reliable channel, but also not being a full terminal emulator.

(emphasis mine)

I'm not sure this is strictly true? Specifically, as far as I'm aware it's more a matter of what specific terminal one is emulating. For example, the VT520 has a "desktop feature" to "Review previous lines"; this keeps a "Review Previous Lines Buffer", which (quoting section 2.8.3 of the EK-VT520-RM document (PDF)) behaves as follows:

The Review previous lines feature when selected re-arranges page memory into a single page and a scroll back buffer (transcript). Lines of text scrolled up from the first line of the page are saved in the scroll back buffer (replacing the oldest lines saved if any). Pressing Control with the up or down arrow keys pans the screen window up or down allowing you to view lines previously scrolled off the top of the page up to the number of lines saved in the scroll back buffer. If the page size is larger than the window size, pressing Control with the up arrow key first pans to the top of the page and then pans into the scroll back buffer.

Any time lines in the scroll back buffer are available, a small down and/or up arrow appears at the lower right position of the status line to indicate there are additional unseen lines of the page below or above. When any text is received from the host for this session, the screen window is automatically repositioned to show the single page before the display is updated. Switching sessions does not automatically reposition the screen allowing you to view the scroll back data in one window while working in another. The number of lines that can be saved in the scroll back buffer is one page less than the total number of lines (in 25 line pages) allocated to the session virtual terminal. The factory default for Review previous lines is disabled.

You cannot copy and paste from the scroll back buffer.

As far as I can tell, this functionality provides perfect license for a VT520 emulator to provide a line-by-line scrollback buffer. I've not yet gone digging enough to tell when such functionality was first introduced (i.e. whether it predates the VT520). At that point, emitting lines from said buffer into the client environment is merely a matter of the emulator's choices regarding platform integration.

As for the first half (reliable channel), I'm not convinced of that either: in particular, the visible portion of the scrollback buffer could be the "synchronized state", while the scrollback buffer itself could be "server-private state". At that point, you no longer need a reliable channel either. This would relax the "local" part of scrollback buffer, but could possibly recover it by remembering what had already been filled from the terminal-emulation scrollback buffer into the local scrollback buffer, and backfilling via range requests. However, in order to survive unbounded periods of connectivity loss, this would require an unbounded server-side buffer.

[achernya]

The problem is not the VT520 that mosh emulates. The problem is the outer terminal requires a line-oriented output, of every single line. If you want "native scrollback", then mosh needs to deliver, reliably, every single event that happened server-side to the client's outer terminal.

The scrollback buffer can't be synchronized in the way you describe because the scrollback buffer is part of the outer terminal. There are no events (to my knowledge) that the outer terminal sends to mosh to generate scrollback; that's why things like screen and tmux have their own scrollback mechanisms. What you're asking for essentially amounts to making a "moshterm" GUI program.

[zen2]

As far as I have understood mosh implementation uses two buffer: one on client and one on server side and the sync mechanism is using a diff/patch of both buffers to keep in sync. So I suppose that the buffer size is equal to the number of characters displayed on your current terminal so basically height x width characters. On another side, I can see that mosh doesn't interpret the classical keys input of shift+PageUp/PageDown natively so these keys are not used at all since it is not even treated natively by readline library.

So I wonder if it is not possible to implement a scrollback by pages simply by setting the buffer size by multiplying the size of the buffer by an integer in order to make the buffer represent a finite number of full pages for the current terminal and interpret keys to change page by page or line by line. Like it the sync mechanism continue to do is job and a simple offset applied permit to display the scrollback. The drawback is that won't work at all if you resize the terminal but actually mosh doesn't handle it too for its buffer so I don't think it is a real problem any way.

It is a similar that the way used for old school vertical bitmap scrolling where you simple change offset of the video memory pointer on a virtual screen more higher than real screen.

[AkechiShiro]

No solution was found possible for this I guess ? as I've read @achernya's latest comment right ? Maybe this feature is simply not possible and we should use screen/or any other terminal multiplexer for scrollback buffer ?