bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Constantine Kharlamov]

Emacs says: "x-clipboard-yank is obsolete since 25.1; use ‘clipboard-yank’ instead." The problem is that clipboard-yank doesn't work same way as x-clipboard-yank does.

x-clipboard-yank always uses clipboard content, which is exactly what I need. I.e. if I set (setq select-enable-clipboard nil) to not clutter my clipboard with kills, I only get content from the clipboard. (don't get me wrong, kill-ring is very cool, and I extensively use it in evil-mode. But I prefer to explicitly point when I want a content in the clipboard, which happens an order of magnitude rarer than usage of kill-ring).

clipboard-yank uses a kill-ring instead. So if I set (setq select-enable-clipboard nil), every usage of the function gives me a random text that may or may not be in the clipboard.

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Eli Zaretskii]

> From: Constantine Kharlamov <Hi-Angel@yandex.ru>
> Date: Wed, 21 Jun 2017 17:29:40 +0300
> 
> x-clipboard-yank always uses clipboard content, which is exactly what I need. I.e. if I set (setq select-enable-clipboard nil) to not clutter my clipboard with kills, I only get content from the clipboard. (don't get me wrong, kill-ring is very cool, and I extensively use it in evil-mode. But I prefer to explicitly point when I want a content in the clipboard, which happens an order of magnitude rarer than usage of kill-ring).
> 
> clipboard-yank uses a kill-ring instead.

I see the same call to 'yank' in both clipboard-yank and
x-clipboard-yank, so I'm not sure I understand what difference in
behavior you see (you also didn't say which version of Emacs did you
use).  Can you show a reproducible recipe starting from "emacs -Q"
which could be used to see the problem?

Thanks.

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Constantine Kharlamov]

On 21.06.2017 22:10, Eli Zaretskii wrote:
>> From: Constantine Kharlamov <Hi-Angel@yandex.ru>
>> Date: Wed, 21 Jun 2017 17:29:40 +0300
>>
>> x-clipboard-yank always uses clipboard content, which is exactly what I need. I.e. if I set (setq select-enable-clipboard nil) to not clutter my clipboard with kills, I only get content from the clipboard. (don't get me wrong, kill-ring is very cool, and I extensively use it in evil-mode. But I prefer to explicitly point when I want a content in the clipboard, which happens an order of magnitude rarer than usage of kill-ring).
>>
>> clipboard-yank uses a kill-ring instead.
> 
> I see the same call to 'yank' in both clipboard-yank and
> x-clipboard-yank, so I'm not sure I understand what difference in
> behavior you see (you also didn't say which version of Emacs did you
> use).

Sorry. It's 26.0.50, Archlinux, emacs-gitᴬᵁᴿ. However the first time I saw the problem at least 1.5 year ago on Ubuntu. It's just that I never reported, but today I started worrying.

> Can you show a reproducible recipe starting from "emacs -Q"
> which could be used to see the problem?
> 
> Thanks.

Well, for collecting the steps turned out `(clipboard-yank)` might have another subtle bug. But what I said still holds. Steps:

1. start `emacs -Q`
2. Press M-: to execute `(setq select-enable-clipboard nil)`
3. Copy a text in the system, i.e. outside of Emacs.
4. Press M-: to execute `(clipboard-yank)` (you'll get at the point a content from system clipboard)
5. Press M-< M-d (so now you have the word ";; This" in kill-ring)
6. Press M-: to execute `(clipboard-yank)`

	You will see ";; This" got pasted at point, not the value in the system clipboard.

7. Press M-: to execute `(x-clipboard-yank)`

	You will see content from the system clipboard got pasted at point.

The subtle bug I just found is an inconsistent behavior: if you skip the 4-th step, then at 6-th step you'll see the content from system clipboard. Which is actually what I'd want (i.e. the system clipboard content, not the inconsistent behavior, of course), but in long-term usage it pastes from kill-ring.

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Lars Ingebrigtsen]

Constantine Kharlamov <Hi-Angel@yandex.ru> writes:

> 1. start `emacs -Q`
> 2. Press M-: to execute `(setq select-enable-clipboard nil)`
> 3. Copy a text in the system, i.e. outside of Emacs.
> 4. Press M-: to execute `(clipboard-yank)` (you'll get at the point a
> content from system clipboard)
> 5. Press M-< M-d (so now you have the word ";; This" in kill-ring)
> 6. Press M-: to execute `(clipboard-yank)`
>
> 	You will see ";; This" got pasted at point, not the value in
> the system clipboard.
>
> 7. Press M-: to execute `(x-clipboard-yank)`
>
> 	You will see content from the system clipboard got pasted at point.

Aaah!  This explains the weird behaviour I've been seeing when I'm
trying to paste stuff from the clipboard -- as you say,
`M-x clipboard-yank' doesn't work reliably if you've yanked the
clipboard contents once.

And that's because of this:

(defun gui-selection-value ()
  (let ((clip-text
         (when select-enable-clipboard
           (let ((text (gui--selection-value-internal 'CLIPBOARD)))
             (if (string= text "") (setq text nil))

             ;; Check the CLIPBOARD selection for 'newness', is it different
             ;; from what we remembered them to be last time we did a
             ;; cut/paste operation.
             (prog1
                 (unless (equal text gui--last-selected-text-clipboard)
                   text)
               (setq gui--last-selected-text-clipboard text)))))

So, indeed, if you `M-x clipboard-yank', then kill some text in Emacs,
you can't `M-x clipboard-yank' until you've clipboarded some other text,
yanked it, and then clipboarded the original text again.

Fixing this should be pretty trivial -- the following patch should do
the trick, I think (although I haven't tested it).  But I'm not quite
sure about the intended logic here, so I've added Stefan M to the CCs --
perhaps he has some comments.

diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index 739e751d8a..dac04e113e 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -570,7 +570,8 @@ menu-bar-edit-menu
 (defun clipboard-yank ()
   "Insert the clipboard contents, or the last stretch of killed text."
   (interactive "*")
-  (let ((select-enable-clipboard t))
+  (let ((select-enable-clipboard t)
+        (gui--last-selected-text-clipboard nil))
     (yank)))
 
 (defun clipboard-kill-ring-save (beg end &optional region)


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

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> (defun gui-selection-value ()
>   (let ((clip-text
>          (when select-enable-clipboard
>            (let ((text (gui--selection-value-internal 'CLIPBOARD)))
>              (if (string= text "") (setq text nil))
>
>              ;; Check the CLIPBOARD selection for 'newness', is it different
>              ;; from what we remembered them to be last time we did a
>              ;; cut/paste operation.
>              (prog1
>                  (unless (equal text gui--last-selected-text-clipboard)
>                    text)
>                (setq gui--last-selected-text-clipboard text)))))
>
> So, indeed, if you `M-x clipboard-yank', then kill some text in Emacs,
> you can't `M-x clipboard-yank' until you've clipboarded some other text,
> yanked it, and then clipboarded the original text again.
>
> Fixing this should be pretty trivial -- the following patch should do
> the trick, I think (although I haven't tested it).  But I'm not quite
> sure about the intended logic here, so I've added Stefan M to the CCs --
> perhaps he has some comments.

AFAIK this part of the clipboard interaction is one I just preserved
from earlier code when I did my "gui-selection" rework.
I "just preserved" it because I don't really understand how it's
intended to work, nor do I understand enough of the design constraints
to be able to come up with my own design of how it should work :-(

Your patch looks acceptable to me (it is also disappointing because
it doesn't really help understand how this thing is intended to work,
but it follows the same principles as the ones I followed).


        Stefan

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> AFAIK this part of the clipboard interaction is one I just preserved
> from earlier code when I did my "gui-selection" rework.
> I "just preserved" it because I don't really understand how it's
> intended to work, nor do I understand enough of the design constraints
> to be able to come up with my own design of how it should work :-(

*ponder* Well, I guess it's a vague kind of DWIM thing going on...
Since we don't have timestamps on our own kills, and
`select-enable-clipboard' defaults to t, we want to let a clipboard
selection "win" if we haven't yanked it before?  But...  it seems to me
like this is already handled by other logic when putting things on the
kill ring in the first place.

That is, if you "emacs -Q", put something on the clipboard from a
different programme, and when `M-w' something in Emacs, then `C-y' will
insert the latter.

I've tested various things here now, and I'm unable to come up with a
scenario where the current DWIM logic is helpful, really.

Anybody else able to deduce what the point of the code is?  And if they
do, can they put some comments in `gui-selection-value'?

> Your patch looks acceptable to me (it is also disappointing because
> it doesn't really help understand how this thing is intended to work,
> but it follows the same principles as the ones I followed).

:-)

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

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> *ponder* Well, I guess it's a vague kind of DWIM thing going on...
> Since we don't have timestamps on our own kills, and
> `select-enable-clipboard' defaults to t, we want to let a clipboard
> selection "win" if we haven't yanked it before?  But...  it seems to me
> like this is already handled by other logic when putting things on the
> kill ring in the first place.

That pretty much matches my understanding, yes.

> That is, if you "emacs -Q", put something on the clipboard from a
> different programme, and when `M-w' something in Emacs, then `C-y' will
> insert the latter.

Yes, IIUC this is the easy case.  I think the harder case is when we
`M-w` first and then put something on the clipboard with another
application, then do `C-y`.

> I've tested various things here now, and I'm unable to come up with a
> scenario where the current DWIM logic is helpful, really.

Yet AFAICT the kill-ring logic was there already when the clipboard
logic was added, so I'm not sure the duplication is completely redundant.


        Stefan

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Constantine Kharlamov <Hi-Angel@yandex.ru>,  Eli Zaretskii
>  <eliz@gnu.org>,  27442@debbugs.gnu.org
> Date: Mon, 05 Jul 2021 17:28:02 +0200
> 
> *ponder* Well, I guess it's a vague kind of DWIM thing going on...
> Since we don't have timestamps on our own kills, and
> `select-enable-clipboard' defaults to t, we want to let a clipboard
> selection "win" if we haven't yanked it before?  But...  it seems to me
> like this is already handled by other logic when putting things on the
> kill ring in the first place.
> 
> That is, if you "emacs -Q", put something on the clipboard from a
> different programme, and when `M-w' something in Emacs, then `C-y' will
> insert the latter.
> 
> I've tested various things here now, and I'm unable to come up with a
> scenario where the current DWIM logic is helpful, really.

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

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 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

If this is the reason for this check, then removing the setq of 
gui--last-selected-text-clipboard in gui-selection-value, and only set
it in gui-select-text, would fix this problem, too.  I think.

But it's late, and I may be misreading the code.  :-)

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

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  Hi-Angel@yandex.ru,  27442@debbugs.gnu.org
> Date: Mon, 05 Jul 2021 22:11:22 +0200
> 
> (kill-new "foo")
> (gui-selection-value)
> => nil
> 
> Could we use a different way to identify this situation that's less
> fragile?

AFAIK, there's no reasonable way of doing a better check.

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

Where would that time stamp come from?

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

I admit I don't really understand what the patch does and how.  can
you elaborate on that?

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.
>
> Where would that time stamp come from?

Selections have time stamps, so we could compare the time stamp from
when we pushed the data onto the clipboard with what we have.  I think?
It's the timestamp parameter to/from
XSetSelectionOwner/XConvertSelection/x_get_window_property_as_lisp_data.

It's been years since I messed around with that stuff, so I could well
be misremembering what the meaning of the timestamps are.

>> 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.
>
> I admit I don't really understand what the patch does and how.  can
> you elaborate on that?

It just makes `M-x clipboard-yank' defeat the "check for duplicates"
logic and always return the contents of the clipboard.

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

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  Hi-Angel@yandex.ru,  27442@debbugs.gnu.org
> Date: Tue, 06 Jul 2021 16:18:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> >
> > Where would that time stamp come from?
> 
> Selections have time stamps

In the clipboard? supported by all the systems and all the clipboard
varieties out there?

> so we could compare the time stamp from
> when we pushed the data onto the clipboard with what we have.  I think?

Is it reasonable to assume that close enough time stamps necessarily
mean we are the owner?

> > I admit I don't really understand what the patch does and how.  can
> > you elaborate on that?
> 
> It just makes `M-x clipboard-yank' defeat the "check for duplicates"
> logic and always return the contents of the clipboard.

But that would mean we throw away the baby together with the
bathwater, no?  Why would we want to do that?

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> In the clipboard? supported by all the systems and all the clipboard
> varieties out there?

I don't know -- probably by the ones we care most about.

> Is it reasonable to assume that close enough time stamps necessarily
> mean we are the owner?

It's a millisecond timestamp on the clipboard -- so it's a better guess
than what we have.

>> It just makes `M-x clipboard-yank' defeat the "check for duplicates"
>> logic and always return the contents of the clipboard.
>
> But that would mean we throw away the baby together with the
> bathwater, no?  Why would we want to do that?

No, this is the command `M-x clipboard-yank' only, which should always
return the clipboard contents.  The DWIM stuff in this gui selection
function is for `C-y' and friends.

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

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  Hi-Angel@yandex.ru,  27442@debbugs.gnu.org
> Date: Tue, 06 Jul 2021 18:20:30 +0200
> 
> >> It just makes `M-x clipboard-yank' defeat the "check for duplicates"
> >> logic and always return the contents of the clipboard.
> >
> > But that would mean we throw away the baby together with the
> > bathwater, no?  Why would we want to do that?
> 
> No, this is the command `M-x clipboard-yank' only, which should always
> return the clipboard contents.  The DWIM stuff in this gui selection
> function is for `C-y' and friends.

Ah, okay.  Then I guess your fix should be fine, thanks.

bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Ah, okay.  Then I guess your fix should be fine, thanks.

Pushed now (along with a comment that explains the DWIM action better).

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