GNU bug report logs -
#73469
29.4; mouse passing on terminal window generates events
Previous Next
Full log
Message #35 received at 73469 <at> debbugs.gnu.org (full text, mbox):
>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 <at> finder.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 73469 <at> 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
>>
>
This bug report was last modified 246 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.