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

[Ignacio Casso]

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