1

I use mc frequently and it has been running perfectly for years. A while ago (weeks?) mc seems to get confused by the mouse wheel and prints what seem to be ANSI Escape sequences on the screen similar to these:

[97;14;10M[96;15;10M[97;16;10M[96;16;10M[96;16;10M

I cannot find any ANSI sequences with 3 numbers and M though. 97 seems to mean roll up and 96 seems to mean roll down. The other numbers are a mystery.

Also strange is that this fault is not predictable and starts at any time while using mc. And, to make it even stranger: I can have one mc open in a terminal, which is working ok, and, in another terminal, an mc which fails.

The last seems to indicate that the fault isn't a common factor (like maybe gpm or so).

I'm using Slackware 14.2, urxvt (v9.22), and a m$ optical mouse. Anyone have an idea where to look? I also ran mc in rxvt and, in comparison, urxvt seems somehat sluggish scrolling.

Improve this question

2 Answers 2

Reset to default
3

These are urxvt's 1015 extended mouse coordinates, see http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking (and by the way, the second and third numbers are cell coordinates). This protocol extension's primary aim is to support mouse coordinates beyond 223.

Another, more favorable extension is xterm's SGR 1006 mode which addresses the same issue (and more) without some of the drawbacks urxvt's extension has. Xterm's 1006 mode is supposed to obsolete urxvt's 1015 mode.

rxvt-unicode (a.k.a. urxvt), however, is the only terminal emulator I'm aware of that supports mouse events, yet does not support this extension. I talked to its author in Jan 2012 but he refused to implement this mode for reasons I could not understand. Maybe someone should give it another try; it's only a few lines of trivial code that urxvt needs.

Midnight Commander implements this newer and better xterm extension, and no longer implements the urxvt extension. For details see mc tickets 2662 and 2956.

This means that normally mc should ask for an extension that urxvt does not support, and hence continue operating without using any extension (and mouse working only up to column 223).

In your case probably an application performs an unclean exit and leaves this mouse extension enabled which confuses mc (it does not understand what it receives). You can quit mc and then disable this extension by executing echo -ne '\e[?1015l', and finally relaunch mc.

Unfortunately in urxvt-9.21 the command reset does not disable this extension, although it really should. I believe this is a bug.

If this reoccurring problem really bothers you, I recommend you to incorporate the above escape sequence in your prompt (or to switch to another emulator that supports the 1006 extension). Or track down and fix the application that leaves this extension enabled when it quits.

Improve this answer
2
  • Hello @egmont... Wow - this seems to have some history behind the scenes! I've had quite a day, and it's 1:38 am here. I will read you answer more attentively tomorrow. I can tell that I recompiled urxvt earlier, and reinstalled it. Until now, everything seems normal again, and no escape codes are shown anymore, but I haven't used the computer much. I don't think the urxvt executable was damaged before, but I did update some libraries since the previous compilation - maybe that caused the problem. Still, I'd like to know more about the problem. Commented Sep 6, 2016 at 4:43
  • 1
    Never found the application that caused the problem, and it never happened again (2 years! touching wood). My apologies for not coming back earlier! Commented Apr 4, 2018 at 5:10
0

Where I messed up was adding export TERM=xterm to my bash_profile. Bad mistake. This way I've overridden the terminal's default TERM variable. Don't do that.

This completely messed up the mouse control in urxvt for cmus an mc, never again export TERM=... globally, now I removed it. All works great again.

As for the other issue I tried to solve with changing TERM, now only applied where it needs to be, locally: alias vim='TERM=xterm vim' this solved my original issue with the colors in vim in tmux...

Improve this answer
2
  • Thanks for answer, but the TERM= parameter is too important for many programs. Of course, you have to export TERM=rxvt-unicode if you are using urxvt, else any program relying on TERM will be totally confused. This is particularly important if you are doing remote connections (in which case you have to install the rxvt-unicode TERM definition on the accessing machine too (this is not present by default). Commented Apr 4, 2018 at 5:16
  • You're right, thanks for pointing that out. The issue is not with the export itself, but with overriding the terminal's default without much thinking. Just edited my comment above. Commented Apr 7, 2018 at 12:08

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.