Escape sequences on mouse movement when disconnected from SSH session while Micro was opened.

[MostHated]

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.

It seems this happens when you are SSH'd into a server and I believe your connection times out while you have Micro opened. Then it starts doing this. Just after I made a post to a much older thread about a month or so ago, I made a change on one of my boxes and it has not happened since, but I can't remember what it was, so I am going to go searching for it. I am pretty sure I just changed the timeout on the box, though. I fired up a new box and it is happening on that one, which is what prompted / reminded me to come update this.

It seems the only way to stop it is to physically close the terminal window and then go back in.

I do occasionally see it randomly without being disconnected, though, I am not 100% sure of the circumstances in which cause it as it is only sometimes. It might have something to do with changing focus to another window and coming back, but it is quite seldom, and I change window focus all the time, so there much be some other factor. When it does this without being disconnected, it looks like this:

I had opened Micro using an alias, edited a file, saved and then closed it and that was what it looked like. A simply ctrl + c cleared it out and I can go on about my business.

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

[rcx]

#779

[rcx]

Aha. Here are the ConEmu internal states that are linked to the issue.

1. In wslbridge connector, inside tmux. No problematic mouse escape sequences.
   
2. After opening micro. Now there are problems.
   
3. After closing micro. Notice the mouse is still x4C.
   

Now this terminal is messed up till it's restarted.

[rcx]

More sleuthing.

https://github.com/Maximus5/ConEmu/blob/44fb97de59e663d9e81fafa31d95b0fe18c5a2fb/src/ConEmu/SetPgInfo.cpp#L109

https://github.com/Maximus5/ConEmu/blob/master/src/ConEmu/RealConsole.cpp#L15204

https://github.com/Maximus5/ConEmu/blob/1a2363ef646dfe8c225347c3f54eac9a26993130/src/ConEmu/RealConsole.h#L885 (so it is a bitmask)

https://github.com/Maximus5/ConEmu/blob/49afabb3deda050a55a621fdd2be424dcbb6b778/src/common/Common.h#L421

tmm_ANY ... what I presume to be happening is that:

1. micro is telling the terminal to report all mouse events (so mouse selection can work)
2. ConEmu is sending these escape sequences
3. They are not correct

Why do I suspect that this tmm_ANY mode is problematic? Because when I select in ordinary tmux and move my mouse around; works fine, even though the mouse stays in x44 mode, meaning tmm_ANY is off. Seems like it is instead relying on tmm_XTERM = 0x0040, /* Xterm's CSI-style mouse encoding */.

Therefore, my conclusion is:

• ConEmu's emulation of tmm_ANY is likely faulty, or simply that tmux / etc are not equipped to handle them
• Micro is at partially at fault because tmm_ANY is not disabled when exiting micro
• A possible fix could be to rely on the Xterm CSI-style mouse encoding instead and avoid setting the any-event mouse mode altogether.

[rcx]

So where is this tmm_ANY coming from?

https://github.com/Maximus5/ConEmu/blob/1a2363ef646dfe8c225347c3f54eac9a26993130/src/ConEmuCD/ConAnsiImpl.cpp#L1721

OK, but where does micro send this escape 1003? We must dig into tcell.

https://github.com/zyedidia/tcell/blob/master/terminfo/s/screen/term.go#L38

https://github.com/zyedidia/tcell/blob/master/terminfo/x/xterm/term.go#L37

So I suppose the workaround for this is to remove \x1b[?1003%ga%c from the MouseMode string, and rebuild tcell and micro. However this fix is likely specific to ConEmu and I have no guarantee for how other terminals like Gnome, urxvt, etc. will respond! Because virtually everything pretends to be an xterm or screen, no guarantee for how other terminals will take that.

A more robust fix would also unset \x1b[?1003%ga%c when exiting micro but I don't have the knowledge to implement this into tcell or micro. Of course, tools reset and stty sane and friends do not do this. It is totally laughable that an application can mess up your terminal so bad that you have to restart it or restart tmux.

Here is a build of micro with the any-event mouse escapes disabled in case your terminal is buggy like mine, aka ConEmu. https://github.com/ecx86/tcell/releases/tag/12345

I hate terminals so much.

[zyedidia]

Sorry about this problem, it seems like you've done quite a bit of digging to find the source, but there is no good solution in sight. One thing to note is that you can disable the mouse in micro by setting the mouse option to off.

[rcx]

Hey zyedidia,

thanks for taking the time to reply. No hostility from me towards your project, in fact, I actually like it a lot. I didn't want to disable mouse (because I find the mouse support to be really useful and well-done compared to other editors). However, that required fixing the issue with the mouse events.

I agree there is no real solution to this in sight-- the likely solution is to fix the emulation inside ConEmu, but that codebase seems very complicated and I don't want to touch it. Hence the workaround :-)

[xbb]

I had a similar problem in WSL with Windows Terminal and mintty, when moving the mouse cursor and pressing ESC simultaneously.

With 2.0.8 the issue is fixed for me.

Edit: actually there is still something wrong, this time not with mouse movement but mouse scroll + ESC