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

[Ignacio Casso]

Thanks for clarifying, Po Lu!

One final question. Does then Emacs assert ownership of the selection
also when it reads it (C-y) and not only when it sets it (C-k), as I
assumed in my last email? Because otherwise I think my point still
holds, and I didn't see any use of gui-backend-set-selection inside
gui-selection-value (and I could not test it since I'm running Emacs
27).

But never mind, I'll leave it here since I stole too much of your time
already. Just one last minor thing: there is a very minor typo in the
comments on select.el in case you want to fix it (or at least it is in
the github mirror which seems to be up to date). It says:

;; The functionality here is divided in two parts:
;; - Low-level: gui-get-selection, gui-set-selection, gui-selection-owner-p,
;;   gui-selection-exists-p are the backend-dependent functions meant to access
;;   various kinds of selections (CLIPBOARD, PRIMARY, SECONDARY).

But the last two functions are actually gui-backend-selection-owner-p and
gui-backend-selection-exists-p, the others do not exist. For the first
two, they exist for both prefixes gui- and gui-backend-, the second
being lower level.

Regards,

Ignacio

Po Lu <luangruo@yahoo.com> writes:

> Ignacio Casso <ignaciocasso@hotmail.com> writes:
>
>> 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).
>
> You have the wrong mental model of how X selections work.  You can't
> "set" a selection, but instead you assert ownership of it, which means
> other clients will then ask you for its contents.  (Which are always
> kept by you, and never sent to the X server, unless you exit and a
> clipboard manager is willing to take ownership of the selection.)
>
> If Emacs wants to get the value of CLIPBOARD, then it has to first find
> out which client has ownership of that selection, and to ask it for the
> value of CLIPBOARD.  If that ownership information is unavailable, then
> selections will not work at all, so the selection ownership information
> is guaranteed to be reliable as long as selections are working.
>
> Other clipboard systems typically have a counter that is atomically
> incremented each time something is saved to the clipboard.  The client
> can save the value of the counter before it has saved something to the
> clipboard, and compare that to the current value of the counter, to
> determine whether or not it was the last client to have set the value of
> the clipboard.