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:


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.


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|||||
  • 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. – jcoppens Sep 6 '16 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! – jcoppens Apr 4 '18 at 5:10

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|||||
  • 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). – jcoppens Apr 4 '18 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. – slve Apr 7 '18 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.