GNU bug report logs - #53894
27.2; Clipboard copy -> C-y -> M-y -> Same clipboard copy does not push to kill ring

Previous Next

Full log

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

From: Ignacio Casso <ignaciocasso <at> hotmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 53894 <at> debbugs.gnu.org
Subject: Re: bug#53894: 27.2; Clipboard copy -> C-y -> M-y -> Same clipboard
 copy does not push to kill ring
Date: Wed, 09 Feb 2022 13:52:20 +0100

Hi Lars,

I read the debbugs.gnu.org thread about bug#27442 where you try to
figure out the reason behind that logic, and I think the conclusion you
arrive at is incomplete and that the bug I reported might give some more
insight about it. I might be wrong since I have not given that much
though to this, but here is what I mean:

Every time we yank, interprogram-paste-function is called. If it returns
nil we yank from the kill-ring, otherwise the returned string is pushed
to the kill-ring and yanked.

If we then rotate the kill ring, we do not want to paste from the
clipboard anymore, so interprogram-paste-function must return nil if
nothing newer has been copied to the clipboard. The way this is checked
is by just checking whether the clipboard content has changed.

If we do not rotate the kill ring, it doesn't matter if
interprogram-paste-function returns nil since the clipboard content is
already at the top of the kill-ring. In fact we need it to return nil in
order not to duplicate it in the kill ring.

So basically, while the content of the clipboard remains the same, we
want gui-selection-value to return it only the first time we call it
(for this use case at least), and from then onwards the kill ring will
handle it. That would be another reason behind that
logic aside from the one you thought of: ignoring clipboard content if it
was put there by Emacs itself with kill commands (since it's already in
the kill ring too).

This would also answer my original question: unless there was a
timestamp in the clipboard Emacs has indeed no way to know right now if
the exact same string was copied to the clipboard again in-between (in
which case I would expect it to be pushed to the top of the kill-ring
again)

Does it make sense?

Sorry if you had already figured it out or if I am wrong, I did not
understand the whole email thread nor debug this issue in depth. Or if
it's no longer relevant, but since I saw the email thread was less than
one year old I thought that you might want to know.

Regards,

Ignacio


Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Ignacio Casso <ignaciocasso <at> hotmail.com> writes:
>
>> I'm not sure if it's intentional or not, or even if Emacs can do
>> anything about it (maybe since the text is the same, the clipboard is not
>> actually modified and Emacs has no way to know). I just wanted to report
>> it in case it is a bug.
>
> It's intentional:
>
> (defun gui-selection-value ()
>   (let ((clip-text
>          (when select-enable-clipboard
>            (let ((text (gui--selection-value-internal 'CLIPBOARD)))
>              (when (string= text "")
>                (setq text nil))
>              ;; When `select-enable-clipboard' is non-nil,
>              ;; killing/copying text (with, say, `C-w') will push the
>              ;; text to the clipboard (and store it in
>              ;; `gui--last-selected-text-clipboard').  We check
>              ;; whether the text on the clipboard is identical to this
>              ;; text, and if so, we report that the clipboard is
>              ;; empty.  See (bug#27442) for further discussion about
>              ;; this DWIM action, and possible ways to make this check
>              ;; less fragile, if so desired.
>              (prog1
>                  (unless (equal text gui--last-selected-text-clipboard)
>                    text)
>                (setq gui--last-selected-text-clipboard text)))))
>
> But it's pretty fragile DWIM action, and is frequently not what I mean,
> so I often resort to `clipboard-yank' instead to ensure that I really
> get the clipboard contents.

Previous Next

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