Bug#182292: Debian Bugs information: logs for Bug#182292
> Message received at submit@bugs.debian.org:
> 1) Start mc on xterm
> 2) Ctrl-O
> 3) Start new mc
> 4) Ctrl-O Ctrl-O
> 5) F10
> 6) Ctrl-O
> 7) F10
> Now try to use mouse for working with clipboard. Mouse is broken on this
> xterm. Pressing the buttons results in something like "h,#h,"
The symptom is that the procedure leaves xterm in a "mouse reporting"
state where mouseclicks are translated to escape sequences that are
sent down the pseudotty. Mc uses this to enable point-and-click with
the mouse, and usually turns it off before it exits.
(The reason why the behavior does not occur with rxvt is that mc
refuses to even try to enable mouse reporting when $TERM is not
xterm-foo, even though rxvt does implement the feature).
Here is what happens with two telescoped mc processes, where I only
note occurences of the control sequences
^[[?1001s "save mouse reporting flag"
^[[?1001r "restore mouse reporting flag"
^[[?1000h "set mouse reporting mode"
^[[?1000l "clear mouse reporting mode"
------state-----
I type mc 1 sends mc 2 sends currrent saved
1 mc <enter> save off off
2 set on off
3 (draws itself)
4 ^O clear off off
5 restore off off
6 mc <enter> save off off
7 set on off
8 (draws itself)
9 ^O save on on
10 set on on
11 (draws itself)
12 ^O clear off on
13 restore on on
14 F10 <enter> ("exit y/n?" box)
15 clear off on
16 restore on (!!) on
17 ^O save on on
18 set on on
19 (draws itself)
20 F10 <enter> ("exit y/n?" box)
21 clear off on
22 restore on on
The problem arises between the two ^O's in line 9 and 12. The inner mc
never sees these keypresses; they are captured by the outer one. The
outer mc temporarily turns mouse reporting on, but tries to preserve
the terminal state by wrapping its actions in a save/restore
pair. Superficially, that works well: after line 13 the terminal is
still in mouse reporting mode just as before line 9. But the save in
line 9 has clobbered the old saved value from line 6 that the inner mc
plans to restore in step 16. Therefore mouse reporting is still on
efter step 16, and this faulty state is again preserved by the
save/restore pair in lines 17-22.
In my HO, xterm is acting in agreement with its specification; the
basic problem is that mc uses "save" and "restore" as if they were
"push" and "pop", which they aren't. But it does not have many other
options; xterm does not offer control sequences to query the current
mouse-tracking state.
An attempt to solve the problem by having the to mc's actively
coordinate their state is doomed to fail - the scenario could work
with *any* mouse-aware program in place of the inner mc. A
quasi-sultion would work in most case woud be that all programs the
use mouse reporting stopped generatinng save and restore and simply
turing mouse reporting off unconditionally when they release the
screen. Then, reporting would sometimes be unexpectedly off after
mc has interrupted itself, but that is surely better than it being
unexpectedly *on*.
--
Henning Makholm "Special: see sub-basement floors 3 and 4"
Reply to: