GNU bug report logs - #28868
25.1; Feature request: isolate kill ring from window system cut and paste buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28868 in the body.
You can then email your comments to 28868 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Brian Julin <BJulin <at> clarku.edu>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 25.1; Feature request: isolate kill ring from window system cut and
 paste buffer
Date: Mon, 16 Oct 2017 18:11:29 +0000

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line  a valid email address.  After a delay of up
to one day, you should receive an acknowledgment at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from 'emacs -Q':

Recipe:

1) Start a terminal based emacs
2) Type a line of text
3) kill the line of text
4) yank the line of text
5) Paste a line of text from another window into emacs
    (use either clipboard or quick-selection X11 buffer, does not matter)
6) Yank a line of text

Problem:

Ever since xterm.el added bracketed paste mode support, the #6 yank
yanks the line of text which was pasted.  Though this is stated in the
code comments as the desired behavior, it certainly is not the way I
personally wish emacs to behave.  I much prefer the window system
clipboard and selection system to have absolutely nothing to do at all
with the emacs kill-ring (unless I run a command like x-clipboard-yank
explicitly.)

Normally when an upgrade starts behaving in a new and upsetting
manner, I would google and find, after quite a tedious process of
reading random forum threads for tangentially related issues until
I find one that actually addresses my issue, that there was a configuration
variable available for my /etc/site-start.d files to customize such a behavior.
In this case there appears to be none.  You can prevent emacs
from contaminating the window system clipboard and selection buffers
with various directives depending on what exactly you are trying to prevent,
and you can try to prevent an interprogram-paste-function from being installed,
and try to prevent a tty-setup-hook from being installed, but those
two approaches either are nontrivial to get to work due to modes
coming in and ignoring defaults, or did not disable this behavior if I indeed did
manage to get them to work.

(Note I did try 'M-: (setq interprogram-paste-function nil)' interactively
but even that did not change the behavior.) 

Nothing in the currrent-kill code seems to suggest the presence of a
directive other than that with which to control this behavior.

Workaround:

use TERM=vt100 in emacs environment to avoid loading xterm.el.

---


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    'bt full' and 'xbacktrace'.
For information about debugging Emacs, please read the file
/usr/share/emacs/25.1/etc/DEBUG.


In GNU Emacs 25.1.1 (x86_64-pc-linux-gnu)
 of 2017-09-15, modified by Debian built on trouble
System Description:     Debian GNU/Linux 9.1 (stretch)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/\
usr/share/emacs/site-lisp
 --with-sound=alsa --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/\
usr/share/emacs/site-lisp
 --with-sound=alsa --with-x=no --without-gconf --without-gsettings
 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs25-wN2qS3/emacs25-25.1+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
JPEG SOUND GPM DBUS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)...done
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...done
Loading /etc/emacs/site-start.d/99-kill-crap.el (source)...done
Loading /etc/emacs/site-start.d/99-only-morons-search-insensitively.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)
Mark set
current-kill: Kill ring is empty

Load-path shadows:
/usr/share/emacs25/site-lisp/cmake-data/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs/25.1/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/25.1/lisp/textmodes/rst

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
regexp-opt rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode
easymenu cl-loaddefs pcase cl-lib mail-prsvr mail-utils image term/xterm
xterm time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify multi-tty
make-network-process emacs)

Memory information:
((conses 16 86276 5204)
 (symbols 48 19092 0)
 (miscs 40 48 99)
 (strings 32 14696 4400)
 (string-bytes 1 420012)
 (vectors 16 9830)
 (vector-slots 8 380290 17193)
 (floats 8 160 229)
 (intervals 56 224 23)
 (buffers 976 19))

Message #8 received at 28868 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Brian Julin <BJulin <at> clarku.edu>
Cc: 28868 <at> debbugs.gnu.org
Subject: Re: bug#28868: 25.1;
 Feature request: isolate kill ring from window system cut and paste
 buffer
Date: Mon, 16 Oct 2017 21:56:45 +0300

> From: Brian Julin <BJulin <at> clarku.edu>
> Date: Mon, 16 Oct 2017 18:11:29 +0000
> 
> Ever since xterm.el added bracketed paste mode support, the #6 yank
> yanks the line of text which was pasted.  Though this is stated in the
> code comments as the desired behavior, it certainly is not the way I
> personally wish emacs to behave.  I much prefer the window system
> clipboard and selection system to have absolutely nothing to do at all
> with the emacs kill-ring (unless I run a command like x-clipboard-yank
> explicitly.)
> 
> Normally when an upgrade starts behaving in a new and upsetting
> manner, I would google and find, after quite a tedious process of
> reading random forum threads for tangentially related issues until
> I find one that actually addresses my issue, that there was a configuration
> variable available for my /etc/site-start.d files to customize such a behavior.
> In this case there appears to be none.

Thank you for your report.  Would you be willing to submit a patch
that introduces a defcustom which will allow to disable bracketed
paste mode even if the terminal support it?

Message #11 received at 28868 <at> debbugs.gnu.org (full text, mbox):

From: Brian Julin <BJulin <at> clarku.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "28868 <at> debbugs.gnu.org" <28868 <at> debbugs.gnu.org>
Subject: Re: bug#28868: 25.1;	Feature request: isolate kill ring from window
 system cut and paste	buffer
Date: Mon, 16 Oct 2017 20:20:38 +0000

Eli Zaretskii worte:

> > From: Brian Julin <BJulin <at> clarku.edu>
> > Date: Mon, 16 Oct 2017 18:11:29 +0000
> >
> > Normally when an upgrade starts behaving in a new and upsetting
> > manner, I would google and find, after quite a tedious process of
> > reading random forum threads for tangentially related issues until
> > I find one that actually addresses my issue, that there was a configuration
> > variable available for my /etc/site-start.d files to customize such a behavior.
> > In this case there appears to be none.
>
> > Thank you for your report.  Would you be willing to submit a patch
> > that introduces a defcustom which will allow to disable bracketed
> > paste mode even if the terminal support it?

Well, A) I've probably only written 20 lines of LISP in my life and
B) Entirely disabling bracketed paste mode and this are a bit orthogonal...
there's a case for both to be sure, given bracketed paste mode is
arguably the wrong side on which (and method with which) to fix the
paste-hijacking security issue and you may want paren-finding and other
things turned on during a paste for some reason.  Also C) I think it's a design
issue that maybe deserves some discussion rather than arbitrarily adding
more spaghetti variables/directives.

Message #14 received at 28868 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Brian Julin <BJulin <at> clarku.edu>, 28868 <at> debbugs.gnu.org
Subject: Re: bug#28868: 25.1; Feature request: isolate kill ring from window
 system cut and paste buffer
Date: Sun, 29 Oct 2017 16:24:46 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Mo., 16. Okt. 2017 um 20:58 Uhr:

> > From: Brian Julin <BJulin <at> clarku.edu>
> > Date: Mon, 16 Oct 2017 18:11:29 +0000
> >
> > Ever since xterm.el added bracketed paste mode support, the #6 yank
> > yanks the line of text which was pasted.  Though this is stated in the
> > code comments as the desired behavior, it certainly is not the way I
> > personally wish emacs to behave.  I much prefer the window system
> > clipboard and selection system to have absolutely nothing to do at all
> > with the emacs kill-ring (unless I run a command like x-clipboard-yank
> > explicitly.)
> >
> > Normally when an upgrade starts behaving in a new and upsetting
> > manner, I would google and find, after quite a tedious process of
> > reading random forum threads for tangentially related issues until
> > I find one that actually addresses my issue, that there was a
> configuration
> > variable available for my /etc/site-start.d files to customize such a
> behavior.
> > In this case there appears to be none.
>
> Thank you for your report.  Would you be willing to submit a patch
> that introduces a defcustom which will allow to disable bracketed
> paste mode even if the terminal support it?
>
>
Does this need a new user option, or shouldn't the behavior rather respect
the value of `select-enable-clipboard'?

[Message part 2 (text/html, inline)]

Message #17 received at 28868 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: BJulin <at> clarku.edu, 28868 <at> debbugs.gnu.org
Subject: Re: bug#28868: 25.1; Feature request: isolate kill ring from window
 system cut and paste buffer
Date: Sun, 29 Oct 2017 20:26:22 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sun, 29 Oct 2017 16:24:46 +0000
> Cc: Brian Julin <BJulin <at> clarku.edu>, 28868 <at> debbugs.gnu.org
> 
> Does this need a new user option, or shouldn't the behavior rather respect the value of
> `select-enable-clipboard'? 

I'd say a separate option, because someone might want to treat pasting
separately in GUI and in text-mode frames.

But that's me; perhaps we should hear from others.

Thanks.

Message #20 received at 28868 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: BJulin <at> clarku.edu, Philipp Stephani <p.stephani2 <at> gmail.com>,
 28868 <at> debbugs.gnu.org
Subject: Re: bug#28868: 25.1; Feature request: isolate kill ring from window
 system cut and paste buffer
Date: Fri, 03 Sep 2021 09:47:05 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Does this need a new user option, or shouldn't the behavior rather
>> respect the value of
>> `select-enable-clipboard'? 
>
> I'd say a separate option, because someone might want to treat pasting
> separately in GUI and in text-mode frames.
>
> But that's me; perhaps we should hear from others.

By default, "emacs -Q" does not push pasted text onto the kill ring, so
it'd make sense if "emacs -Q -nw" didn't, either.  However, the variable
we have that controls this is `select-enable-primary', which ... has
other side effects, too.  So using that here would be really confusing.

So I've added a new xterm-specific defcustom to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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