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 [EMAIL PROTECTED]:
>
> > 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
[EMAIL PROTECTED] | did not like.
http://people.debian.org/~branden/ | -- John Dean
pgpU4D2hnkkfv.pgp
Description: PGP signature
