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

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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.

> 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.  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?

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