RIS does not reset mouse mode state or encoding #11838

@skyline75489 commented on GitHub (Dec 18, 2020):

So, are you using mosh or just using plain ssh? I'd recommend mosh if you need to resume work smoothly.

@skyline75489 commented on GitHub (Dec 18, 2020): So, are you using mosh or just using plain ssh? I'd recommend mosh if you need to resume work smoothly.

claunia commented

@amie42 commented on GitHub (Dec 18, 2020):

I'd love to use mosh but its not compatible with our setup. I'm new on this job maybe I'll make them to implement some improvements. That would be definitely one. Another one would be: get rid of Windows Workstations at all. But for now, I'm glad I have Windows Terminal at least.

@amie42 commented on GitHub (Dec 18, 2020): I'd love to use mosh but its not compatible with our setup. I'm new on this job maybe I'll make them to implement some improvements. That would be definitely one. Another one would be: get rid of Windows Workstations at all. But for now, I'm glad I have Windows Terminal at least.

claunia commented

@skyline75489 commented on GitHub (Dec 18, 2020):

I'm not a pane user so I don't have much say about this issue. I believe someone in the team will have more insights.

@skyline75489 commented on GitHub (Dec 18, 2020): I'm not a pane user so I don't have much say about this issue. I believe someone in the team will have more insights.

claunia commented

@amie42 commented on GitHub (Dec 18, 2020):

Yeah, maybe I should return to tmux.

@amie42 commented on GitHub (Dec 18, 2020): Yeah, maybe I should return to tmux.

claunia commented

@zadjii-msft commented on GitHub (Dec 18, 2020):

What random text are you seeing exactly? We might be able to better diagnose if we knew what the text was exactly.

Are you using mouse mode in vim? Does pressing ↟ not recall the previous command? Because that should work even if the ssh session didn't exit cleanly.

It sounds to me like something on the remote machine is requesting mouse mode input, then the connection is being broken, leaving the Terminal in mouse mode without bash expecting it.

This might also be related to #381, maybe a little bit of #8020,

@zadjii-msft commented on GitHub (Dec 18, 2020): What random text are you seeing exactly? We might be able to better diagnose if we knew what the text was exactly. Are you using mouse mode in vim? Does pressing <kbd>↟</kbd> _not_ recall the previous command? Because that should work even if the `ssh` session didn't exit cleanly. It sounds to me like something on the remote machine is requesting mouse mode input, then the connection is being broken, leaving the Terminal in mouse mode without `bash` expecting it. This might also be related to #381, maybe a little bit of #8020,

claunia commented

@amie42 commented on GitHub (Dec 18, 2020):

Yes, I'm using mouse mode in vim
↟ does work. but I don't use it as the terminal stays useless even after ssh reconnects
some example "random output":
9+#9+ (on left click)
2'#2' (left click a couple of seconds later without even moving the mouse)
0.#0. (left click after moving the mouse a little)
<backtick>0. (small scroll upwards)

It sounds you have a great theory as it's reproducible in Gnome Terminal 3.38.1 on my native ~~debian~~ Arch/Manjaro that way as well. I had to kill -9 the ssh client though.
Anything I could do from user perspective to reset the "mouse mode"? Maybe something for a bashrc?

@amie42 commented on GitHub (Dec 18, 2020): Yes, I'm using mouse mode in vim ↟ does work. but I don't use it as the terminal stays useless even after ssh reconnects some example "random output": ` 9+#9+` (on left click) ` 2'#2'` (left click a couple of seconds later without even moving the mouse) ` 0.#0.` (left click after moving the mouse a little) `<backtick>0.` (small scroll upwards) It sounds you have a great theory as it's reproducible in Gnome Terminal 3.38.1 on my native ~~debian~~ Arch/Manjaro that way as well. I had to kill -9 the ssh client though. Anything I could do from user perspective to reset the "mouse mode"? Maybe something for a bashrc?

claunia commented

@amie42 commented on GitHub (Dec 18, 2020):

In Gnome Terminal reset fixes the issue. this is probably the reason why I wasn't annoyed by that issue that much before

@amie42 commented on GitHub (Dec 18, 2020): In Gnome Terminal `reset` fixes the issue. this is probably the reason why I wasn't annoyed by that issue that much before

claunia commented

@oising commented on GitHub (Dec 18, 2020):

@amie42 If you're on windows 10 and you have WSL installed, you can either run reset from there, or if you're running powershell / cmd or another windows shell, wsl reset will work.

@zadjii-msft It would nice to build terminal reset a la tset(1) directly into windows terminal on the GUI.

@oising commented on GitHub (Dec 18, 2020): @amie42 If you're on windows 10 and you have WSL installed, you can either run `reset` from there, or if you're running powershell / cmd or another windows shell, `wsl reset` will work. @zadjii-msft It would nice to build terminal reset a la tset(1) directly into windows terminal on the GUI.

claunia commented

@zadjii-msft commented on GitHub (Dec 18, 2020):

I'm mildly concerned that reset doesn't fix this. I don't know how to check whatever reset is emitting off the top of my head, but if that works in gnome-terminal it should work in WT. I'd bet that there's some component of it that's being lost in the conpty layer, so the Terminal is still in mouse mode, but the client and conpty aren't.

@zadjii-msft commented on GitHub (Dec 18, 2020): I'm mildly concerned that `reset` doesn't fix this. I don't know how to check whatever `reset` is emitting off the top of my head, but if that works in `gnome-terminal` it should work in WT. I'd bet that there's some component of it that's being lost in the conpty layer, so the Terminal is still in mouse mode, but the client and conpty aren't.

claunia commented

https://invisible-island.net/ncurses/man/tset.1.html

@oising commented on GitHub (Dec 18, 2020):

@zadjii-msft

reset - reinitialization
       When invoked as reset, tset sets the terminal modes to "sane" values:

       o   sets cooked and echo modes,

       o   turns off cbreak and raw modes,

       o   turns on newline translation and

       o   resets any unset special characters to their default values

       before doing the terminal initialization described above.  Also, rather
       than  using  the  terminal initialization strings, it uses the terminal
       reset strings.

       The reset command is useful after a program dies leaving a terminal  in
       an abnormal state:

       o   you may have to type

               <LF>reset<LF>

           (the line-feed character is normally control-J) to get the terminal
           to work, as carriage-return may no  longer  work  in  the  abnormal
           state.

       o   Also, the terminal will often not echo the command.

So I guess it's $TERM specific

@oising commented on GitHub (Dec 18, 2020): @zadjii-msft ```text reset - reinitialization When invoked as reset, tset sets the terminal modes to "sane" values: o sets cooked and echo modes, o turns off cbreak and raw modes, o turns on newline translation and o resets any unset special characters to their default values before doing the terminal initialization described above. Also, rather than using the terminal initialization strings, it uses the terminal reset strings. The reset command is useful after a program dies leaving a terminal in an abnormal state: o you may have to type <LF>reset<LF> (the line-feed character is normally control-J) to get the terminal to work, as carriage-return may no longer work in the abnormal state. o Also, the terminal will often not echo the command. ``` https://invisible-island.net/ncurses/man/tset.1.html So I guess it's $TERM specific

claunia commented

@oising commented on GitHub (Dec 18, 2020):

if WT is xterm-color, it seems the reset string is:

oisin@BEASTIEBOOK3:/mnt/c/Users/OisinGrehan$ infocmp xterm-color | grep rs[123].*
        rs2=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8, sc=\E7,

@oising commented on GitHub (Dec 18, 2020): if WT is xterm-color, it seems the reset string is: ```text oisin@BEASTIEBOOK3:/mnt/c/Users/OisinGrehan$ infocmp xterm-color | grep rs[123].* rs2=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8, sc=\E7, ```

claunia commented

@zadjii-msft commented on GitHub (Dec 18, 2020):

I guess I'm more concerned with whatever @amie42's client actually is emitting, rather than what it should be emitting. I believe that WSL sets the TERM to xterm256-color, but who knows if it's getting changed before it's being used.

@amie42 could you share the output of infocmp | grep rs[123].* from your Debian instance, without running ssh?

@zadjii-msft commented on GitHub (Dec 18, 2020): I guess I'm more concerned with whatever @amie42's client actually is emitting, rather than what it _should be_ emitting. I believe that WSL sets the TERM to `xterm256-color`, but who knows if it's getting changed before it's being used. @amie42 could you share the output of ` infocmp | grep rs[123].*` from your Debian instance, without running `ssh`?

claunia commented

@amie42 commented on GitHub (Dec 19, 2020):

IIRC, reset on native ~~Debian~~ Arch/Manjaro Gnome Terminal fixes the issue. In Windows Terminal it does not. I'm going to check back on Monday. But I won't even remotely touch a windows box in my spare time. Have a great weekend everyone!

@amie42 commented on GitHub (Dec 19, 2020): IIRC, `reset` on native ~~Debian~~ Arch/Manjaro Gnome Terminal fixes the issue. In Windows Terminal it does not. I'm going to check back on Monday. But I won't even remotely touch a windows box in my spare time. Have a great weekend everyone!

claunia commented

@amie42 commented on GitHub (Dec 19, 2020):

From my native ~~Debian~~ Arch|Manjaro Laptop: New Terminal Window. I never ran ssh from this process :
infocmp | grep rs[123].* rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,

@amie42 commented on GitHub (Dec 19, 2020): From my native ~~Debian~~ Arch|Manjaro Laptop: New Terminal Window. I never ran ssh from this process : `infocmp | grep rs[123].* rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, `

claunia commented

@amie42 commented on GitHub (Dec 21, 2020):

Confirmed: reset in the windows terminal does not fix the issue: neither in version 1.5, nor in 1.4.
I'll post the output of infocmp | grep rs[123].* of the Windows Terminal in a new comment

@amie42 commented on GitHub (Dec 21, 2020): Confirmed: `reset` in the windows terminal does not fix the issue: neither in version 1.5, nor in 1.4. I'll post the output of `infocmp | grep rs[123].*` of the Windows Terminal in a new comment

claunia commented

@amie42 commented on GitHub (Dec 21, 2020):

WT1.4:
xterm-256color|xterm with 256 colors, colors#256, cols#80, it#8, lines#24, pairs#32767, acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, rmso=\E[27m, rmul=\E[24m, rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
WT 1.5:
rmso=\E[27m, rmul=\E[24m, rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,

@amie42 commented on GitHub (Dec 21, 2020): WT1.4: ` xterm-256color|xterm with 256 colors, colors#256, cols#80, it#8, lines#24, pairs#32767, acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, rmso=\E[27m, rmul=\E[24m, rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, ` WT 1.5: ` rmso=\E[27m, rmul=\E[24m, rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, `

claunia commented

@amie42 commented on GitHub (Jan 6, 2021):

Any update here? would you need any other input from my side?

@amie42 commented on GitHub (Jan 6, 2021): Any update here? would you need any other input from my side?

claunia commented

@amie42 commented on GitHub (Feb 5, 2021):

The problem still persists in v1.5.10271.0

@amie42 commented on GitHub (Feb 5, 2021): The problem still persists in v1.5.10271.0

claunia commented

@amie42 commented on GitHub (Feb 26, 2021):

The Problem still persists in v1.5.10411.0

@amie42 commented on GitHub (Feb 26, 2021): The Problem still persists in v1.5.10411.0

claunia commented

@amie42 commented on GitHub (Apr 15, 2021):

The Problem still persists in v1.7.1033.0

@amie42 commented on GitHub (Apr 15, 2021): The Problem still persists in v1.7.1033.0

claunia commented