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

[Ignacio Casso <ignaciocasso@hotmail.com>]

Hello again,

After thinking a little bit more about it I realize I have jumped to
conclusions. Sorry about that.

Since in the thread of bug #27442 you focused on the
problem of Emacs being the author of the last clipboard copy, I assumed
that gui-backend-selection-owner-p meant just that. But for that a
variable would suffice, and I see now that it is a low level function,
which probably means that the concept of ownership is at a Window
Manager level. If that's the case, if as soon as Emacs reads the
clipboard it asserts ownership of it without modifying it, that can be
used to know when there is something new in the clipboard, since the
owner will have changed to the application who put it there. Then
gui-backend-selection-owner-p would indeed solve all the problems,
gui--last-selected-text-clipboard would no longer be needed, and if it
was removed it would solve the bug I reported.

I should have known better than to think I could be right and you wrong
about some Emacs code I've just started looking at. Sorry about that.

Regards,

--Ignacio


Ignacio Casso <ignaciocasso@hotmail.com> writes:

> Hi all,
>
> Did you read my last email? I think you got some things wrong. I'll
> explain it again inline.
>
> First, about my original concern:
>
>>> In addition, I believe the OP claims that the algorithm we use to
>>> decide (on X) when to return nil is flawed, or at least ruins his use
>>> case.  I don't think I succeed to understand the rationale for that
>>> claim, FWIW.
>>
>> Here's the case to reproduce:
>>
>> In external program, "copy" a text
>> In Emacs: C-y M-y
>> In external program, "copy" the same text
>> In Emacs: C-y
>>
>> This C-y will not yank the text.
>
> Lars is right here
>
>>> So now the only issue left (for me) is that I don't think I understand
>>> why the OP doesn't like this: after all, the original text from the
>>> clipboard is still available in the kill ring, and can be pasted given
>>> enough M-y, or using the Edit menu-bar menu, or using the new feature
>>> of M-y when it is invoked not after C-y or another M-y.
>>
>> But it's surprising (and frustrating) to click on "Copy text" in a
>> different application and then (sometimes) not being able to yank it
>> with `C-y'.
>
> And here too. But I don't really care that much, I was just reporting
> it. As you said, you can find it in the kill ring or use clipboard-yank,
> and it's a really uncommon scenario.
>
> And now about the DWIM logic in gui-selection-value:
>
>> No, the problem is still present on the trunk.  But I suspect that after
>> you introduced the `gui-backend-selection-owner-p' test in
>> gui--selection-value-internal, the logic surrounding
>> gui--last-selected-text-clipboard in gui-selection-value is no longer
>> necessary, and should just be removed now.
>>
>> But I haven't analysed the problem in depth, and I don't know how this
>> works on non-X systems -- perhaps that DWIM logic in gui-selection-value
>> is still necessary on some systems.
>
> That logic is still necessary. gui-selection-value is called every time
> we yank, and we only want it to return non-nil when there is something
> new there. If there is, it's pushed to the top of the kill ring and
> yanked, and from then onwards the kill ring handles it. Otherwise, i.e.,
> if its the same as gui--last-selected-text-clipboard, it returns nil. So
> gui-selection-value will almost always return nil for that reason, and
> it's in fact gui-backend-selection-owner-p what is probably unnecessary,
> since it achieves the same as setting gui--last-selected-text-clipboard
> to the string being killed in the first place, which gui-select-text
> already does.
>
> In particular, removing that logic would not solve the problem I
> reported. The only way to solve it would be with clipboard
> timestamps, which are probably not worth to use if this is the only
> problem they solve (although I saw a comment about them being needed
> also to resolve discrepancies between clipboard and primary selection).
>
> Regards,
>
> --Ignacio