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

[Thomas Dickey]

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.

> 
> > 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>
> > http://invisible-island.net
> > ftp://ftp.invisible-island.net
> 

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

signature.asc
Description: PGP signature