unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jared Finder via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Francesco Potortì" <Potorti@isti.cnr.it>
Cc: 73469@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#73469: 29.4; mouse passing on terminal window generates events
Date: Sun, 29 Sep 2024 12:10:57 -0700	[thread overview]
Message-ID: <8f37fa3bd8db84dc9bd90346d88f4200@finder.org> (raw)
In-Reply-To: <E1supfU-0000000HYX7-1Cu9@tucano.isti.cnr.it>

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





  reply	other threads:[~2024-09-29 19:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-25 12:23 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
2024-09-25 15:45 ` Eli Zaretskii
2024-09-27  7:48   ` Francesco Potortì via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-27 10:25     ` Eli Zaretskii
2024-09-28 17:50       ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-29  8:52         ` Francesco Potortì via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-29 19:10           ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-09-29 20:07             ` Francesco Potortì via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-05 15:15               ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-19  7:04                 ` Eli Zaretskii
2024-10-19  8:24                   ` Francesco Potortì via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f37fa3bd8db84dc9bd90346d88f4200@finder.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=73469@debbugs.gnu.org \
    --cc=Potorti@isti.cnr.it \
    --cc=eliz@gnu.org \
    --cc=jared@finder.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).