bug#73469: 29.4; mouse passing on terminal window generates events

[Eli Zaretskii <eliz@gnu.org>]

Ping!  Francesco, could you please provide the additional info
requested by Jared?

> Date: Sat, 05 Oct 2024 08:15:41 -0700
> From: Jared Finder <jared@finder.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 73469@debbugs.gnu.org
> 
> On 2024-09-29 13:07, Francesco Potortì wrote:
> > 
> > This is under Screen
> > ________________________________________________________________
> > Sun Sep 29 21:38:26 CEST 2024
> > 
> > ~$ echo -e "\e[?1000h"
> > 
> > ~$ echo -e "\e[?1003h"
> > 
> > ~$ echo -e "\e[?1006h"
> > 
> > ~$ 
> > #35;40;5M35;40;5M35;40;5M35;40;5M35;40;5M35;40;5M35;40;5M35;40;5M35;40;5M35;40;6M35;40;6M35;40;7M35;40;7M35;40;7M35;40;7M35;40;7M35;40;8M35;40;8M35;40;8M35;40;8M35;40;8M35;40;8M35;40;8M35;40;9M35;40;9M
> > ~$ # above, I just moved the mouse pointer
> 
> This is odd and indicates of a bug outside of Emacs.
> 
> A mouse move with no buttons down should be sending lowercase m, not 
> uppercase M. This is aligned with what the Emacs lossage reported, 
> though we can't see the initial ESC [ M characters as the terminal tries 
> to interpret that.
> 
> > ~$ # now, I will click left, then right, then center
> > ~$ #0;41;9M0;41;9m35;41;9M35;41;9M1;41;9M1;41;9m
> > ~$ # right did not work, as it is taken by mate-terminal
> 
> This may be ok; it depends on if it is prefixed with ESC [ M (bad!) or 
> ESC [ < (good!).
> 
> > ~$ # now, I rotate the wheel
> > ~$ # 
> > 64;41;9M64;41;9M64;41;9M65;41;9M65;41;9M65;41;9M65;41;9M64;41;9M64;41;9M65;41;9M65;41;9M
> 
> This is also odd.
> 
> The wheel is supposed to look mouse buttons 4 and 5 which is accurately 
> represented here. However, the terminal is only sending button down 
> (suffixed with M) and no button up (suffixed with m).
> 
> > ~$ # now, disabling mode 1015
> > ~$  echo -e "\e[?1015l"
> 
> All the events here looked the same.
> 
> > Now the same on the same terminal, but outside of Screen
> 
> Again, all the events here looked the same, though like before I 
> couldn't see if the prefix was ESC [ M (bad!) or ESC [ < (good!).
> 
> Thank you so much for all this testing. I'm fairly confident this is not 
> an issue in Emacs and probably not in screen as well. That means we can 
> rely on view-lossage for accurate character reporting to diagnose what's 
> going on, which is nice because we can see the escape sequence prefix.
> 
> 
> For next steps I am considering adding a workaround and want to verify 
> the behavior is easy to implement and maintain. Unfortunately since I 
> can't reproduce your issue locally, I do need more info from you if you 
> have time. I want to see those escape sequence prefixes for both today 
> and the state prior 0695c9e8599b5036a80361571e7cb0ea9fdead99 from 2020 
> which added mouse movement tracking.
> 
> Can you please report the lossage for the same mouse move, mouse button, 
> and mouse wheel test within Emacs and report the lossage? You already 
> did mouse move earlier, so I'm just looking for mouse button click and 
> mouse wheel scroll.
> 
> After that, can you please try altering xterm-mouse--tracking-sequence, 
> replacing 1003 with 1002 before enabling xterm-mouse-mode. (This was the 
> state prior to mouse movement tracking being supported.) Please do this 
> in a fresh Emacs session before enabling xterm-mouse-mode the first 
> time. Then report the same mouse move (I'm expecting no characters 
> here), mouse click, and mouse wheel lossage.
> 
> Thank you!
> 
>    -- MJF
>