Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

screen corruption #259

Closed
klement opened this Issue · 18 comments

4 participants

@klement

when I do a 'less' or 'more' commands, sometimes the status bar is missing. the cursor is placed correctly where it should be, but the string "--More--(8%)" is not there. It looks like a random garbage of characters. Most of the time it consists of a black square, then a few white squares and again black square.

Anothere issues is when having 2 vim windows in screen and switching between these two. After switch, the screen does not update until there is a scrolling inside the vim window.

@kmcallister
Collaborator

What version of Mosh are you using? What operating system?

What's your outer terminal? Are there any other terminal emulators in the mix, e.g. screen or tmux?

Did you confirm that the corruption does not occur if you replace mosh with ssh?

@klement

[ksekera@ksekera-fedora ~]$ mosh --version
mosh 1.1.95
Copyright 2012 Keith Winstein mosh-devel@mit.edu
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

operating system is linux.
the terminal used is "terminal" from gnome 3.
I am using screen.

And yes, without mosh, there is no issue

@keithw
Owner

Do you have the problem in xterm? The GNOME 3 terminal is apparently very buggy. Also, please use the released version of 1.2 now that it is out (although nothing changed between 1.1.95 and 1.2 that should affect this).

@klement

I did a quick test in xterm.
When I am inside the screen and inside that I run vim and I uses ctrl+6 to switch between the window buffers, nothing happens until I do something else(e.g. move cursor).

Example:
standard ssh: ctrl+6 inside vim : immediate change of buffer
mosh: ctrl+6 inside vim: nothing, on next cursor move - change of buffer

this behaviour is the same for xterm or gnome 3 terminal

@kmcallister
Collaborator

That's because Ctrl+6 (really, Ctrl+^) is the Mosh escape key sequence, like Screen's Ctrl+A. You can send a literal Ctrl+^ with Ctrl+^ ^, as documented on the usage page and in the manpage. See also #215.

But what does that have to do with screen corruption in less?

@klement

Hmmm, really? Ctrl+6 does not require me holding down the shift key while Ctrl+^ does. (Otherwise, it's a '6', not a '^').

I thought that this is the same issue which manifests with the more/less screen corruption.

I'd say this needs to be fixed too.

@kmcallister
Collaborator

I thought that this is the same issue which manifests with the more/less screen corruption.

Why? What do they have in common?

@klement
@achernya

I've given up on Gnome 3 on Fedora and would recommend using urxvt256c, available in the rxvt-unicode-256color package.

@klement
@kmcallister
Collaborator

The ctrl+6 issue still needs to be fixed. Should I file a separate bug?... On the second ctrl+6, there is a sequence of two > consecutive ctrl+6s sent to the app.

Yeah, I noticed this before actually. Since you've confirmed it, I'll open the bug.

@kmcallister
Collaborator

Oh, no, this is actually correct. You need to type Ctrl+^ ^, not Ctrl+^ Ctrl+^. In the latter case (and all other unrecognized Ctrl+^ sequences) we send the whole sequence.

@klement
@kmcallister
Collaborator

There is no Ctrl+6 character. Control characters in ASCII are 0x40 below the "regular" character, and 6 is only 0x36. If you hold Control and press 6, your terminal probably sends the Ctrl+^ character, 0x1E.

Anyway, the problem is that you held down Control for the second keypress. You need to send the bytes 1E 5E, which is done by pushing Control-6 or Control-Shift-6, and then Shift-6 (aka ^).

(These instructions assume a US layout.)

@klement
@kmcallister
Collaborator

Not yet (without editing the source). That feature request is #215.

Again, though, you can send Ctrl+^ by pressing Ctrl+^ ^. I agree this is cumbersome; whether it "ruins" the vim feature is subjective I suppose.

@kmcallister
Collaborator

As for the original less corruption, it sounds like this is a bug in VTE, the GNOME library common to gnome-terminal and roxterm. We already ran into another of these as #115.

If you want to track this down, you can grab a typescript using the script command, and confirm that cating the typescript produces the corruption in gnome-terminal. Then we can look at the file and confirm that Mosh is producing reasonable terminal control codes. If that's the case, you can submit the typescript to the VTE developers with a bug report.

@keithw
Owner

Closing as this does not seem to be a Mosh bug.

@keithw keithw closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.