Ticket #4063 (new defect)

Opened 4 months ago

Last modified 4 months ago

mc compiled with slang support does not handle mouse

Reported by: macias Owned by:
Priority: major Milestone: Future Releases
Component: mc-tty Version: master
Keywords: Cc: egmont
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

This report is "fork" of https://midnight-commander.org/ticket/3954.

In my case I have openSUSE Tumbleweed with KDE3 Konsole with mc which is compiled against slang. When I click mouse, the clicks are not translated into clicks but into characters which appears in command line. It looks like one character takes two clicks, and the character shown depends on the line the mouse cursor is in.

For example:
row 0 (i.e. the top one) -- !
row 1 -- "
row 2 -- #
row 3 -- $

It does not look random, it is just ASCII-7.

When I run gpm the mouse behaviour does not change. The only change is when I run mc from xterm -- there mouse is handled correctly.

Change History

comment:1 Changed 4 months ago by andrew_b

  • Component changed from mc-core to mc-tty

comment:2 Changed 4 months ago by egmont

Thanks for opening a new one!

There are two strange things. One is that Konsole generates the legacy sequences for you rather than the new extended ones. The other is that I think mc should still accept the old ones (although maybe the kmous thing causes troubles here, too).

You say it's broken for you in Konsole, but works in Xterm.

What's your $TERM in these? If they are different (e.g. konsole-256color vs. xterm-256color), please swap them, try in Konsole after an export TERM=xterm-256color and in Xterm with export TERM=konsole-256color (or whatever the actual value in the other terminal was). Which one does what?

What's the behavior in gnome-terminal (or if you don't want to install the GNOME stack, try vte-2.91 from the vte-tools package)? You might also try kitty, pterm from the putty package, terminology – please make a note of the behavior and $TERM's value too.

Re the compilation error: You need to install the ncurses development package. Unfortunately I'm not sure what it's called, on the Tumbleweed package search page I can only find ncurses-devel-32bit and ncurses-devel-static, neither sounds like a proper 64bit dynamic lib, but give them (and other similarly sounding packages) a try. It would be great if you could repeat the previous tests with 4 different mcs: slang/ncurses, and with/without the patch from 3954; but don't worry about it now, testing with tumbleweed's package is probably fine for now. Or if you can test the slang build with and without the patch, that's also excellent!

comment:3 Changed 4 months ago by egmont

  • Cc egmont added

comment:4 Changed 4 months ago by macias

You say it's broken for you in Konsole, but works in Xterm.

Yes, and for the record in my old openSUSE Harlequin (released in 2014) I also have KDE3 Konsole and xterm. KDE3 was consireded frozen then (and now) so this part doesn't change. Yet (old) mc works there fine without gpm and/or setting TERM.

Ok, so now, I tested KDE3 Konsole, gnome-terminal, pterm, xterm, kitty, xfce4-terminal. After all tests it looks $TERM env does not change a thing. I tested the default settings and "opposite" one, first one goes the default one:

konsole -- xterm, xterm-256color
xterm -- xterm, xterm-256color
gnome-terminal -- xterm-256color, xterm
xfce4-terminal -- xterm-256color, xterm
kitty -- xterm-kitty, xterm
pterm -- linux, xterm-256color

Only two do not work -- konsole (as described in original post) and pterm. Here mouse clicks are treated yet in another way -- for mouse click the screen is treated as somewhat plain text. Single click does nothing, double click selects the word, triple click selects the row.

As for compiling, I have ncurses-devel of course, and this library is found. Only this particular function is problematic, here is the output of configure with the context:

checking for library containing addwstr... -lncursesw
checking for library containing stdscr... no
configure: error: Cannot find a library providing stdscr

So it looks like stdscr is in some way outside ncurses. I tried both 5 and 6 version, same outcome.

comment:5 Changed 4 months ago by egmont

Oh, wait... something I missed so far... do you really have KDE3 Konsole on Tumbleweed? That is, a fresh and crispy base system, with fresh and crispy ncurses/terminfo, combined with an 11+ year old terminal emulator? (Konsole received support for the SGR 1006 mouse mode extension in Sep 2012, version 4.10.)

I can reproduce your issue, with slang only, if I have a new terminfo (containing kmous=\E[<), and I pretend that the terminal does not support SGR 1006 mouse mode. I do this latter by querying the terminal line with tty, then starting up mc, and then from another terminal issuing an echo -ne '\e[?1006l' > /dev/pts/xxx (substituting with tty's previous output) to disable the extension.

mc could sure introduce some hardwired hack to support your use case, it's not that hard. I might do it one day, although I consider supporting such old systems very low priority (as opposed to ticket 3954 which is a problem on modern systems).

I'm not sure, however, if mc should do that. I'm somewhat inclined to say that your base system is broken, your terminal emulator sets up TERM which then refers to a terminfo entry that describes features that your terminal does not support. Your distribution, or whoever ships KDE3 (or Trinity?) to you should fix this somehow (perhaps by backporting SGR 1006 mouse mode support to Konsole), or you could also fix this for yourself by picking a different TERM, or installing an older terminfo entry (at least for mouse support) under ~/.terminfo/x/xterm-256color.

I'm not sure if mc should work around broken setups. I'm curious to hear mc developers' opinions on this.

comment:6 Changed 4 months ago by egmont

The fix seems to be as simple as replacing

xmouse_seq = NULL;

with

xmouse_seq = ESC_STR "[M";

in 3954's patch (and updating the comment to refer to this ticket too). At least it fixes your situation for me.

I'm sorry but I'm too lazy to verify this change for all various cases (ncurses vs. slang, old vs. new kmous, terminal supporting or not supporting 1006 – that's at least 8 cases to verify).

comment:7 Changed 4 months ago by macias

First of all many, many thanks for the support!

Yes, I really do have KDE3 :-D If it ain't broken, don't fix it. And seriously I am not a number catcher, and Red Queen curse is not appealing to me (in order to stay put you have to move forward). Ok, enough philosophy :-).

As for mc itself and backward compatibility, if it is an enhancement and does break things I would opt for "yes", but I am afraid it would be this or that (i.e. new systems) + time constraints reality. And besides thanks to you, there are workarounds :-).

"that describes features that your terminal does not support."

Yes, it might be the case, especially considering the TERM is just a name without versioning.

"perhaps by backporting SGR 1006 mouse mode support to Konsole"

Good point, thank you. Once I try to move to Trinity (currently I have plain KDE3) I will check this option.

"you could also fix this for yourself by picking a different TERM"

And here are the first good news. I hit the page https://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic and entered various values. And when using "TERM=rxvt" mouse kicked in. I am so happy!

"installing an older terminfo entry (at least for mouse support)"

Honestly I only partially understand what should I do. I tried to google but I am afraid I use not helpful phrases for the search.

"The fix seems to be as simple as replacing"

I still use slang when compiling mc (I didn't figure out ncurses yet) and with TERM=xterm it also worked!

So once again, thank you very much for your help.

comment:8 Changed 4 months ago by macias

Little update: I was so focused on mouse that I didn't notice "rxvt" indeed works with mouse but mis-translates a lot of keys (cursors, tab for example, I got "B"'s instead of cursor-down for example). So patch is much better solution.

Note: See TracTickets for help on using tickets.