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

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

On 2024-09-29 01:52, Francesco Potortì wrote:
>>>> I have found the culprit: it is xterm-mouse-mode.
>> 
>> Could you please reshare the lossage, making sure you are moving the
>> mouse around over an otherwise empty buffer and not holding any
>> modifiers or mouse buttons?
> 
> Here you are. This is the mouse moving on an empty region of the 
> terminal frame I'm using under Screen, after M-x xterm-mouse-mode, 
> without touching any mouse buttons, wheels or keyboard modifiers:
> 
>  3 5 ; C-<mouse-1> 7 0 ; 1 1 M ESC [ M 3 5 ; C-<mouse-1> 7 0 ; 1 1 M 
> ESC [ M 3 5 ; C-<mouse-1> 7 0 ; 1 1 M ESC [ M 3 5 ; C-<mouse-1> 7 0 ; 1 
> 1 M ESC [ M 3 5 ; C-<mouse-1> 7 0 ; 1 1 M ESC [ M 3 5 ; C-<mouse-1> 7 0 
> ; 1 1 M ESC [ M 3 5 ; C-<mouse-1> 6 8 ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 
> 6 6 ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 6 6 ; 1 2 M ESC [ M 3 5 ; 
> C-<mouse-1> 6 5 ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 6 5 ; 1 2 M ESC [ M 3 
> 5 ; C-<mouse-1> 6 4 ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 6 1 ; 1 2 M ESC [ 
> M 3 5 ; C-<mouse-1> 5 9 ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 5 7 ; 1 2 M 
> ESC [ M 3 5 ; C-<mouse-1> 5 7 ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 5 6 ; 1 
> 2 M ESC [ M 3 5 ; C-<mouse-1> 5 6 ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 5 5 
> ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 5 5 ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 
> 5 4 ; 1 2 M ESC [ M 3 5 ; C-<mouse-1> 5 4 ; 1 2 M

Thank you.

Reading over the xterm control sequence specs, it looks like somehow 
URXVT (1015) mode got enabled.  This is strange as xterm-mouse-mode only 
enables modes 1000, 1003, 1006, and (depending on user option) 1005.  
The rest of Emacs doesn't enable 1015 either.  Mode 1015 is specifically 
not enabled as it sends the same info as mode 1006 but in a way that can 
be ambiguous relative to other control sequences.

I suspect your terminal emulator or the screen utility is adding this 
additional mode. Can you try running the following commands outside of 
Emacs? I'm curious if a particular combination of screen and the 
terminal emulator is forcing mode 1015 on.

To manually enable the modes, run the following commands at a shell:

echo -e "\e[?1000h" # Enable mouse button down and up reporting
echo -e "\e[?1003h" # Enable mouse movement reporting
echo -e "\e[?1006h" # Change format to use printable numbers instead of 
encoded bytes

At this point, moving a clicking the mouse will add characters to the 
input, similar to the lossage listed above.

You can disable these mouse tracking modes by using "l" at the end 
instead of "h":

echo -e "\e[?1000l"
echo -e "\e[?1003l"
echo -e "\e[?1006l"

I'd also be curious if manually disabling mode 1015 does anything with 
the above modes activated. In a shell that's echo -e "\e[?1015l" and in 
Emacs that would be (send-string-to-terminal "\e[?1015l").

If you could try all of the above, in your shell both with and without 
screen running it would be helpful for narrowing down the source of the 
bug. And if evaluating the send-string-to-terminal expression fixes 
things while still supporting mouse clicks and hover events, that's a 
simple workaround I can add to xt-mouse.

> Now I'm doing the same with emacs -Q under a fresh Screen window whose 
> TERM I set to screen.linux:
> 
... lossage elided ...
> 
> Same as above (that is, in a Screen window), with TERM set to 
> xterm-256color:

I hope I can save you some time: there's no need to test different 
values of TERM here. xt-mouse doesn't pay attention to the TERM 
environment variable and just sends the xterm control sequences to the 
terminal.

   -- MJF