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>]

sbaugh@catern.com writes:

> 1. emacs -Q under X, preferably X forwarded over ssh to make things slower.
> 2. (setq save-interprogram-paste-before-kill 2000) (or any other integer)
> 3. Copy some very large data in another X client, so the selection is
> very large.
> 4. (kill-new "foo")
> 5. Observe Emacs hanging as it receives the entire large data from the
> selection owner, and then after receiving it all, discards it because
> it's more than 2000 bytes.
>
> Solution: receive_incremental_selection in xselect.c should support a
> cap on the size of the selection it receives and truncate (or discard,
> returning nil?) the selection if it's larger than that.  And setting
> save-interprogram-paste-before-kill to a numeric value should activate
> this cap.

This is not a bug because you can quit while Emacs is waiting for
selection data to arrive from the owner.  The ICCCM provides no means
for the requestor to terminate an incremental selection transfer before
it completes, and owners may become confused if Emacs abruptly stops
responding to their property changes while a transfer is in progress.
Emacs should avoid doing so unless the user explicitly quits (pointing
to a problem with the selection owner anyway.)

Additionally, the way we deal with potentially long-running data
transfer operations in Emacs is not to apply a limit on the size of the
data being transferred, but to make quitting possible within those
transfers.  What may be slow for you can in fact be perfectly acceptable
for others who are connected to their X servers through faster
connections.