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

[Spencer Baugh]

Po Lu <luangruo@yahoo.com> writes:
> 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.

When you do that, you interrupt the operation which is trying to add a
new kill.  If you interrupt it and try again, you'll just get the same
long delay again.  There's no way to mitigate this from within Emacs,
other than by turning off save-interprogram-paste-before-kill.

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

Is there really no way to avoid a large data transfer in ICCCM?

Is there some way to learn the size of the selection in advance and then
decide not to read it if it's too large?  That would also fit the spec
of save-interprogram-paste-before-kill.

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

Yes, that's why this is a customizable setting rather than hard-coded.