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

["Francesco Potortì via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

Sorry, i have traveled for work for the last two weeks and no time for anything else.  I'll be back soon, but then I'll have to manage my backlog, so I may be forced to delay this answer some more.

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