Re: SGR (1006) all events (1003) mouse tracking issue

[Thomas Dickey]

----- Original Message -----
| From: "U Lysses" <leonid.s.usov@gmail.com>
| To: "Ncurses Mailing List" <bug-ncurses@gnu.org>
| Sent: Sunday, April 24, 2022 8:34:20 PM
| Subject: SGR (1006) all events (1003) mouse tracking issue

| Hi,
| 
| I’ve recently been hacking a mouse support for an ncurses based application, 
and
| came across an unfortunate issue that I really wanted to fix.
| 
| You probably know about the 1003 all events mouse tracking mode that sends 
mouse
| move notifications.
| You probably also know about the inherent limitation of the 1003 mode that 
can’t
| support mouse coordinates above 222 col or line
| 
| There is a 1006 SGR mouse support that fixes the addressing issue, but 
wherever
| I looked, this mode was not available with the all events tracking.
| 
| Until… I figured out the whole terminfo shebang and saw that the 1006 mode
| explicitly states ;1000 as the protocol flavor.
| 
|    XM=\E[?1006;1000%?%p1%{1}%=%th%el%;,
| 
| So I looked around, and, inspired by the tmux example, have been happy to find
| out that tmux and iTerm2 and Terminal on macOS and probably many other
| terminals actually do support the config string of

some do, some don't :-)

| 
|    XM=\E[?1006;1003%?%p1%{1}%=%th%el%;,
| 
| In which case that do all the same things as for the standard 1003 mode, but
| encode the events in the superior 1006(SGR) format.
| 
| All was good until I actually tried working in this mode, and I quickly found
| out that ncurses doesn’t recognize mouse tracking properly in the sgr mode.
| The symptoms are numerous and seemingly random until the root cause is
| understood
| * no motion events until any button press
| * after button press or any other active event (like scroll) motion 
effectively
| **repeats** the last seen event
| * with non-zero mouseinterval it looks even stranger, since it collapses
| consecutive motion events and only reports one after the interval elapses
| 
| In the attachment one can find my take at fixing it with literally one line 
(and
| another two comment lines) in the lib_mouse.c.

thanks (will see).  I'd recently tried something like this,
but have had other things to fix...

| In addition to the oneline fix, there is a test program to observe the actual
| events or raw terminal messages, and a test_mouse.cap file that can be 
compiled
| with
| 
|    tic -x test/test_mouse.cap
| 
| and used to observe the operation before/after the actual library fix.
| The issue is logical and thus I am not providing the full set of files.
| 
| The attached patch is atop
| commit 7395e6deb0a2790cb2505669b2ae74751f926e7c (tag: v6_3_20220423,
| dickey/master)
| Author: Thomas E. Dickey <dickey@invisible-island.net>
| Date:   Sat Apr 23 23:26:44 2022 +0000
| 
| 
| ——
| 
| That is not the end, though. While researching the topic, I have noticed that
| ncurses implementation of the protocol disregards the fact that mouse tracking
| is signaled quite obviously by +32 in the button parameter, by definition:
| 
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Button-event-tracking
| 
| This property allows for unambiguous detection of mouse move with any button
| pressed. The implementation of ncurses, however, doesn’t take advantage of 
this
| fact, and reports mouse move as no-button event, with some (unreliable)
| heuristics to tell mouse move from mouse release and mouse scroll
| 
| If it seems reasonable, I could propose another patch that would revise the
| current logic for both x10 and sgr modes and allow for delivering button-press
| states along with the REPORT_MOUSE_POSITION bit set. This could, however, 
break
| existing applications which might not expect the button pressed bit set even
| though they’re really tracking just that with their current code, but with the
| existing implementation see no button press in each of the position tracking
| events despite that being the case.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://ftp.invisible-island.net