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

[Ignacio Casso]

Well my point in this case was gui--last-selected-text-clipboard being
still necessary, since you were suggesting to remove it in the email
thread:

>> 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.
>
> Indeed, it should be removed for the platforms where
> `gui-backend-selection-owner-p' does work.


I'll explain what I mean one final time since you have not really
addressed it yet, so I don't know if I'm wrong or you didn't understood
what I meant. Otherwise I'll leave it at that, since there is no point
in having this discussion while I'm running Emacs 27 and have to look at
the most recent code in Github. I'll go step by step:

- gui-selection-value is called every time we yank (of course, since we
  need to know if anything new was added to the clipboard)

- When it returns non-nil, the text is pushed to the kill ring,
  according to C-h v interprogram-paste-function. From then onwards we
  want the kill ring to handle it.

- Therefore, the next time we yank, we don't want gui-selection-value to
  return the clipboard again, since it's already in the kill-ring, and
  it would be pushed again, duplicating the top of the kill-ring, or if
  it had rotated, pushing down the current top.

- Thus we need a mechanism to ensure we return nil if the clipboard has
  not changed. I understand that originally it was checking if the text
  was the same with gui--last-selected-text-clipboard.

- It was my impression that you though in the email thread of bug #27442
  that the only reason behind that variable was checking that it was not
  Emacs itself the one that had copied to the clipboard, in which case
  we also would want get-selection-value to return nil since the text
  would also be in the kill ring already. I pointed in my second email
  that the reason I just explained may be another, equally important
  reason, and insisted in the third.

- In my last emails I though, wrongly, that in Emacs 28 that mechanism
  had been replaced by asserting selection ownership (without altering
  the selection text, so other programs don't know the difference) as
  soon as the selection was read, and checking whether ownership had
  changed. This assumption was reinforced by you suggesting that
  gui--last-selected-text-clipboard was no longer necessary, which would
  indeed be true in that case, but not now, and you suggesting that
  removing it would fix the bug I originally posted, which again would
  be true in that case, but it is not now (it would, but it would
  introduce new, worse bugs).

I hope it is clearer now what I mean. Of course it all could be that my
mental model of clipboards or my understanding of
gui-backend-selection-value are still wrong: all this depends on my
assumption that repeated calls to gui-selection-value would return the
clipboard text over and over again as long as Emacs does not kill or
other application copies to the clipboard.

Regards,

Ignacio

Po Lu <luangruo@yahoo.com> writes:

> Ignacio Casso <ignaciocasso@hotmail.com> writes:
>
>> One final question. Does then Emacs assert ownership of the selection
>> also when it reads it (C-y)
>
> Not that I know of, no; the ownership remains unchanged.
>
>> and not only when it sets it (C-k), as I assumed in my last email?
>> Because otherwise I think my point still holds
>
> AFAIU the problem is that if you do this:
>
>   - Kill some text in Emacs
>   - C-y
>   - Cut the same text in another program
>
> then that same text is not pushed onto the kill ring again, when you
> press C-y.  I don't understand why Emacs would have to own the clipboard
> in order to fix that.
>
> Thanks.