reassign 182292 mc retitle 182292 mc: thinks terminal mouse reporting is a stack rather than a toggle thanks Thank you verry much for your analysis, Henning. On Sat, Apr 26, 2003 at 08:19:14AM +0200, Henning Makholm wrote: > > 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" > -- G. Branden Robinson | The Rehnquist Court has never Debian GNU/Linux | encountered a criminal statute it branden@debian.org | did not like. http://people.debian.org/~branden/ | -- John Dean
Attachment:
pgpKBkgDOrtZw.pgp
Description: PGP signature