GNU bug report logs - #27442
Un-obsolete x-clipboard-yank, or provide analogous functional

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 27442 <at> debbugs.gnu.org, Hi-Angel <at> yandex.ru
Subject: bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
Date: Mon, 05 Jul 2021 22:11:22 +0200

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

> Please also try with save-interprogram-paste-before-kill non-nil.

As far as I can tell, that's not really affected by the code in
gui-selection-value, or vice versa.

But...  Hm...  poking at this a bit more:

When select-enable-clipboard is non-nil (the default), 

(kill-new "foo")
(gui--selection-value-internal 'CLIPBOARD)
=> "foo"
gui--last-selected-text-clipboard
=> "foo"

Because we're copying over the string to the clipboard.  So when we're
then yanking back, we're really trying to determine whether we ourselves
was responsible for putting the data on the clipboard, and if that's the
case, we want to ignore the data?  Because:

(kill-new "foo")
(gui-selection-value)
=> nil

Could we use a different way to identify this situation that's less
fragile?  Hm...  I don't really see any with our current low-level
functions.  I think x-get-selection-internal could have returned more
metadata -- the timestamp, for instance, which would have allowed us to
see whether we ourselves really pushed the data to the clipboard.

My analysis here may be wrong, but if this is the reason the code in
that function is the way it is, I think the right fix here is the
trivial patch I proposed, along with more comments in
`gui-selection-value' that explains what the point of the
duplicate-ignoring code is.

-- 
(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.