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

[Thomas Dickey]

On Thu, Apr 28, 2022 at 05:11:43PM -0400, Thomas Dickey wrote:
> On Thu, Apr 28, 2022 at 12:12:49PM +0300, U Lysses wrote:
> > Hi Thomas,
> > 
> > I’m not sure if there are any next steps I could take here? 
> 
> not at the moment: I mostly work on ncurses on Saturdays, and
> (assuming that bug-fixes don't consume the whole day) expect to
> take a closer look at your attachments.

I used the small fix for the library, and tested that with the changes
which I had begun in March for the terminal database (good).

The test_mouse program did not have a copyright notice.
If you can provide that with the same licensing information
as is used in ncurses, I can incorporate that (and make
changes, etc).
 
> > 
> > > On 25 Apr 2022, at 3:51, Thomas Dickey <dickey@his.com> wrote:
> > > 
> > > ----- 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>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature