* bug#28868: 25.1; Feature request: isolate kill ring from window system cut and paste buffer
@ 2017-10-16 18:11 Brian Julin
2017-10-16 18:56 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Brian Julin @ 2017-10-16 18:11 UTC (permalink / raw)
To: 28868
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))
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#28868: 25.1; Feature request: isolate kill ring from window system cut and paste buffer
2017-10-16 18:11 bug#28868: 25.1; Feature request: isolate kill ring from window system cut and paste buffer Brian Julin
@ 2017-10-16 18:56 ` Eli Zaretskii
2017-10-16 20:20 ` Brian Julin
2017-10-29 16:24 ` Philipp Stephani
0 siblings, 2 replies; 6+ messages in thread
From: Eli Zaretskii @ 2017-10-16 18:56 UTC (permalink / raw)
To: Brian Julin; +Cc: 28868
> From: Brian Julin <BJulin@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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#28868: 25.1; Feature request: isolate kill ring from window system cut and paste buffer
2017-10-16 18:56 ` Eli Zaretskii
@ 2017-10-16 20:20 ` Brian Julin
2017-10-29 16:24 ` Philipp Stephani
1 sibling, 0 replies; 6+ messages in thread
From: Brian Julin @ 2017-10-16 20:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 28868@debbugs.gnu.org
Eli Zaretskii worte:
> > From: Brian Julin <BJulin@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#28868: 25.1; Feature request: isolate kill ring from window system cut and paste buffer
2017-10-16 18:56 ` Eli Zaretskii
2017-10-16 20:20 ` Brian Julin
@ 2017-10-29 16:24 ` Philipp Stephani
2017-10-29 18:26 ` Eli Zaretskii
1 sibling, 1 reply; 6+ messages in thread
From: Philipp Stephani @ 2017-10-29 16:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Brian Julin, 28868
[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]
Eli Zaretskii <eliz@gnu.org> schrieb am Mo., 16. Okt. 2017 um 20:58 Uhr:
> > From: Brian Julin <BJulin@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'?
[-- Attachment #2: Type: text/html, Size: 1796 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#28868: 25.1; Feature request: isolate kill ring from window system cut and paste buffer
2017-10-29 16:24 ` Philipp Stephani
@ 2017-10-29 18:26 ` Eli Zaretskii
2021-09-03 7:47 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2017-10-29 18:26 UTC (permalink / raw)
To: Philipp Stephani; +Cc: BJulin, 28868
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 29 Oct 2017 16:24:46 +0000
> Cc: Brian Julin <BJulin@clarku.edu>, 28868@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#28868: 25.1; Feature request: isolate kill ring from window system cut and paste buffer
2017-10-29 18:26 ` Eli Zaretskii
@ 2021-09-03 7:47 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-03 7:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: BJulin, Philipp Stephani, 28868
Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-03 7:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-16 18:11 bug#28868: 25.1; Feature request: isolate kill ring from window system cut and paste buffer Brian Julin
2017-10-16 18:56 ` Eli Zaretskii
2017-10-16 20:20 ` Brian Julin
2017-10-29 16:24 ` Philipp Stephani
2017-10-29 18:26 ` Eli Zaretskii
2021-09-03 7:47 ` Lars Ingebrigtsen
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).