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

[U Lysses]

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 

    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.
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.

fix_sgr_mouse_tracking.patch
Description: Binary data