bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections

[Spencer Baugh <sbaugh@janestreet.com>]

Po Lu <luangruo@yahoo.com> writes:
> Spencer Baugh <sbaugh@janestreet.com> writes:
>
>> The insignificant problem is Emacs potentially getting the wrong
>> selection if we interrupt an incremental selection transfer?
>
> Yes, when the user does so deliberately.
>
>> I'm confused, it seems like that contradicts what you said earlier.
>>
>> If interrupting an incremental selection transfer is an insignificant
>> problem, then there should be no obstacle to automatically interrupting
>> the incremental selection transfer if it's too large.
>
> Interrupting incremental selection transfer _automatically_ is a
> significant problem, because Emacs cannot judge if the selection owner
> is functioning normally.  If the user quits, he has determined that it
> is not, so it is acceptable for Emacs to terminate the transfer there
> and then without considering the consequences to the selection owner and
> future selection transfers.

And yet, we do this today: that's what x-selection-timeout does.  Should
we remove that functionality?

I assume we should not remove that functionality.  So if automatically
interrupting a selection transfer if the owner takes too long is fine,
what's the issue with interrupting it if the owner sends too much data?
Both situations are usually the result of buggy X clients, both
situations would break Emacs if not handled, both situations are
standard considerations for robustness in any network protocol.

>> OK, so we are doing at least as good as other toolkits when it comes to
>> retrieving the selection.  But at my site the UX is still worse than
>> other applications because save-interprogram-paste-before-kill makes
>> taking ownership of the selection block, while for other applications it
>> does not.  And save-interprogram-paste-before-kill is a useful feature,
>> and I want to make it work.
>
> Other programs do not have a kill ring at all.

Yes.  And Emacs does, so it needs to do more work than other
applications to make to work correctly.

>> Yes.  x-selection-timeout is configured to 5 seconds for every user at
>> my site.  They still find it unexpected and complain when killing takes
>> that long.
>
> But do they complain about inserting the contents of the selection
> also taking too long?  Or when a program other than Emacs blocks for
> more than 5 seconds upon Button2 or Ctrl+V?

No, because then they are performing an operation which it makes sense
might block: pasting data copied from another application.  In that
situation, they are fine with it.

> Anyway, this points to a problem with an X client at your site and not a
> problem with Emacs.

No, there is no problem with other X clients.  It is simply that users
expect delays when yanking and don't expect delays when killing.

So, Emacs should be able to configure a different x-selection-timeout
when running the save-interprogram-paste-before-kill logic, to reflect
the fact that users have these different expectations for yanking and
killing.  I don't see why this is objectionable.