Escape sequences written on mouse movement

[TedSinger]

When I ssh into an AWS EC2 instance and use micro, mouse movement inserts nonsense text. Here is a sample: M@4![M@N"][M@2"][MCH"MC2!&!MC3!<"[MC+MCC+9)MC=#MCe&[MCo'[MCo" Usually, that terminal will freeze after a little of this - sometimes as little as 20 characters, sometimes over 100. I can kill micro from a separate process, but then that frozen terminal keeps inserting mangled control codes for all mouse movement and ignores any keyboard input - even after the ssh session is killed. Normally, I'd say this has to be a terminal emulator bug, but the same happens in both Terminator and Xfce Terminal. I couldn't reproduce it with joe, another console editor with mouse support.

I've reproduced this with ssh -X, -x, and -Y. It happens on both the EC2 instance itself and a docker container (see Dockerfile below) running on that instance. It does NOT happen on localhost, even when ssh'ing into a docker container running on localhost.

Commit hash: dd5afc0 (v1.3.1 release) OS: Ubuntu 16.04 Terminal: Terminator, Xfce Terminal

$ cat Dockerfile FROM ubuntu:16.04

RUN useradd ted RUN echo 'ted:<appropriate stuff from /etc/shadow>' | chpasswd -e RUN usermod -a -G sudo ted RUN mkdir /var/run/sshd RUN mkdir /home/ted RUN chown -R ted /home/ted RUN apt-get update

RUN apt-get install -y openssh-server EXPOSE 22 CMD ["/usr/sbin/sshd", "-D"]

Once inside the container, download and unpack micro, invoke it with no arguments, then move the mouse.

[zyedidia]

Good news! The creator of tcell is implementing a fix for this that will probably be better than my hackjob. I expect this will be fixed in the next couple of days.

[ghost]

Great !

[zyedidia]

So the fix has been implemented in tcell but I have yet to update my fork of tcell. I attempted earlier but I wasn't able to get pasting to work properly (correct pasting isn't supported by vanilla tcell). Maybe I'll give this another try soon, but I'm lacking time at the moment.

[ghost]

Fair enough.

Do you think tell will ever accept your fork ? Would be optimal for all

On Sat, 21 Oct 2017, 05:59 Zachary Yedidia, notifications@github.com wrote:

So the fix has been implemented in tcell but I have yet to update my fork of tcell. I attempted earlier but I wasn't able to get pasting to work properly (correct pasting isn't supported by vanilla tcell). Maybe I'll give this another try soon, but I'm lacking time at the moment.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zyedidia/micro/issues/779#issuecomment-338361901, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwk8P0Mhm_Dyt_UHSzdSnXD_NqJrZks5suWw0gaJpZM4Oy6OO .

[rcx]

This seems to happen more often when the terminal size is fullscreen. It is rarer when it only occupies half the screen but still is extremely annoying.

[blainsmith]

This is also still happening for me on build 1.3.5-dev.85-linux64. I can't seem to reproduce the steps consistently, but I think it starts happening after opening an existing file and not a new file for me. I also have the filemanger plugin installed as well.

[rcx]

Happens for any buffer on gnome-terminal. I'm surprised there is no workaround for this; it makes micro almost unusable.

[zyedidia]

The main workaround is to disable mouse support (set mouse off) 😐. I am still unable to reproduce this issue which is very annoying.

[rcx]

Maybe we can setup some debug logging to help diagnose it. Setting mouse off isn't an option to me; it's one of the main selling points for micro unfortunately.

[zyedidia]

Ok I am able to reproduce with the alacritty terminal only for wheel movements. One thing you could try would be to view the raw escape sequences with > raw. If mouse sequences are being split across events as EventKey, that's bad.

[zyedidia]

Okay I found the problem for the issue I was having and fixed it. Hopefully this fixes the issue for you. I have updated the nightly binaries so that you can test the fix if you aren't able to build from source.

[rcx]

Thank you, I will test this tomorrow.

[rcx]

I'm sorry but this still doesn't work. Here are some of the escape sequences that are getting through. I used >raw but I couldn't find a way to escape that mode and save the output.

[<35;106;44
[<35;96;42M
[<35;99;49M
[<35;108;47
[<35;104;42
[<35;104;43
[<35;101;47
[<35;101;39
[<35;98;42M

This doesn't seem to be correlated with the speed at which I'm moving the mouse. My guess is that the second and third arguments are coordinates of the mouse. Notice how all those escapes are the same length. When the coordinates are large (3 digits), then it breaks it. It does not occur when the coordinate is 2 digits from what I have seen. Based on where I am moving around my mouse, if the x cell > 99, it seems to have problems; otherwise, it's fine.

I hope this provides some insight into the issue. I would really like to see this resolved.

[zyedidia]

Okay thanks for the update I am confident that the problem is finally fixed with the latest commit to tcell. I am recompiling the nightly binaries for you to test.

[rcx]

The fix indeed works. Awesome fix, thank you.

[zyedidia]

Great. I think this issue can be finally closed now.

[sQVe]

@zyedidia Sadly I see this problem with 1.4.0-1. I just have to move my mouse in the opened window and it starts typing MC etc sometimes. Highly annoying. Ping if I can provide you with any helpful information.

EDIT: This actually seems to only happen with my Trackball (CST L-Trac).

[DanielPower]

I've only had this happen once since 1.4.0, but I quit micro after editing and saving a file, and it pasted an escape sequence into my terminal.

It did not write any escape sequences to the file while editing, as was the previous issue. But when I closed micro, I was left with an escape sequence on my terminal that I had to backspace out.

[sQVe]

@zyedidia I switched to micro-git and compiled. Not seeing any problems with escape sequences anymore. Currently flawlessly running:

% micro --version                                                                                                                                           
Version: 1.4.1-26
Commit hash: 397c294
Compiled on February 13, 2018

I have to set my $TERM to xterm-256color and do a bunch of custom bindings for urxvt to work but that's not that big of a deal. You can find my Xresource file here: https://github.com/sQVe/kodama-dotfiles/blob/e45871937ee5ab3c352f43985429560d3a30daf3/Xresources

[DanielPower]

It just happened to me again for the second time since 1.4.0 released. I opened a file, scrolled down, selected a block of text, deleted it, and then saved the file. When I quit Micro, some escape sequences were printed to my terminal.

[daniel@daniel-arch ~]$ micro ~/.config/albert/albert.conf 
^[[<51;45;8M^[[<51;45;7M[daniel@daniel-arch ~]$ 51;45;8M51

There was a little more at the end of the last escape sequence. I started to erase it before realizing it may be useful for debugging.

I tried to revert the file to exactly the contents it had before, and make the same edit, but I did not get the escape sequences again. I am however having one other bug with this same file, and I'm not sure if it's related. When I open the file in micro, half of the time when I open this file it has full syntax highlighting. The other half of the time, only strings are highlighted.

Edit: I'm still on 1.4.0. I see there's been some changes to syntax highlighting since stable. Perhaps this issue is already fixed in the latest build.

[cs96and]

I'm seeing escape characters in the editor when using ConEmu + SSH, or ConEmu + WSL (Windows Susbsystem for Linux).

ConEmu + WSL still shows the "Pasted clipboard" message. That message does not appear with ConEmu + SSH though.

Using Putty + SSH, or Windows command prompt to WSL works fine, so this seems related to ConEmu in some way.

I'm using the latest precompiled version (1.4.0)

$ micro --version
Version: 1.4.0
Commit hash: af520cf
Compiled on January 26, 2018

[MostHated]

Sorry for the thread necro. I am getting this same issue in Tilix. I had 3 terminal windows opened (1 terminal split into 3) and one of them started doing it but not the others. I was SSH'd into my GCP server and was using Micro when it started.

micro --version Version: 1.4.1 Commit hash: 1856891 Compiled on August 10, 2018

[Igetin]

I experienced this problem on 1.4.*, and it’s still happening on the latest release (2.0.1). It happens both locally and over SSH; whenever I’m selecting text via mouse and move the cursor down so that the view scrolls alongside the selection, escape sequences are outputted in the terminal after exiting micro. I’ve reproduced the error on both Xfce Terminal and GNOME Terminal.

I think I’ve seen escape sequences get printed in some other cases too, but I couldn’t come up with anything else right now.

$ micro --version
Version: 2.0.1-dev.26
Commit hash: 7c71995
Compiled on February 12, 2020
$ xfce4-terminal --version
xfce4-terminal 0.8.7.4 (Xfce 4.12)
$ gnome-terminal --version
# GNOME Terminal 3.28.2 using VTE 0.52.2 +GNUTLS -PCRE2

[dittoslash]

Scrolling down and moving mouse around simultaneously rapidly deletes the whole buffer.

$ micro --version  
Version: 2.0.1  
Commit hash: 7c1995  
Compiled on Feburary 12, 2020  
$ urxvt -h 
rxvt-unicode (urxvt) v9.2.2 - released: 2016-01-23   

[rcx]

This seems to be happening still in ConEmu on WSL :( Very interestingly, even after I close micro escape sequences get written to the terminal when I move my mouse until I restart ConEmu. So it may be a bug in ConEmu?

[rcx]

One cause of this issue is likely to do with terminal emulators with buggy any-event mouse-mode support. This includes ConEmu. The workaround is to avoid setting that mode (ANSI escape 1003). For those users I have created a workaround that you can install here.

[zyedidia]

Does this happen with an editor like Vim as well (make sure that mouse tracking is enabled in Vim)? Given your description, it sounds like the broken pipe killed micro, and micro wasn't able to reset the terminal mode properly, leading to an incorrect terminal state (mouse tracking should not be enabled in general).

I've just run some tests when running kill and kill -9 on micro and Vim, and in both cases micro doesn't reset the terminal state properly, whereas Vim properly resets it for kill. I think it should be possible to intercept the terminate signal and shut down properly, which may also fix the broken pipe issue.

To be clear, this issue describes mouse sequences being written into the micro buffer, not into the terminal after micro has closed, and I believe this issue is truly fixed at this point. For that reason, I'll close the issue now, and also update back when I have implemented the terminate signal handling.