GNU bug report logs - #24419
25.1.50; xterm-mouse-mode appears to disable bracketed paste

Previous Next

Package: emacs;

Reported by: Philipp Stephani <p.stephani2 <at> gmail.com>

Date: Mon, 12 Sep 2016 13:20:01 UTC

Severity: normal

Found in version 25.1.50

Full log


View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: 24419 <at> debbugs.gnu.org
Subject: bug#24419: 25.1.50; xterm-mouse-mode appears to disable bracketed paste
Date: Mon, 12 Sep 2016 14:34:31 +0000
[Message part 1 (text/plain, inline)]
Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Mo., 12. Sep. 2016 um
15:20 Uhr:

>
> Start emacs with emacs -Q -nw from an xterm.  Select some text in some
> other X window.  Then middle-click in Emacs.  The selection is inserted
> using bracketed-paste, as expected.  The lossage for this event is
>
> ESC [ 2 0 0 ~ [xterm-paste]
>
> Now run M-x xterm-mouse-mode, and middle-click again.  You get a message
>
> gui-get-primary-selection: No selection is available
>
> and nothing is inserted.  The lossage is
>
> ESC [ < 1 ; 3 7 ; 1 0 M ESC [ < 1 ; 3 7 ; 1 0 m [mouse-yank-primary]
>
> so the command is detected properly, just nothing is inserted.
>
>
I don't know whether we can do anything about this. This is probably an
issue/missing feature in XTerm: even if we get a mouse-yank-primary event,
we can't get the X selection (unless OSC-52 is enabled). So XTerm should
send the bracketed paste (or even the standard paste events) even if
extended mouse tracking is enabled. Does anybody know whether this issue
has already been discussed in some XTerm forum?
[Message part 2 (text/html, inline)]

This bug report was last modified 8 years and 278 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.