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:

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

Then I guess the solution is to temporarily disable
`save-interprogram-paste-before-kill' if a quit arrives while it is
reading selection data.

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

There is none.

> Is there some way to learn the size of the selection in advance 

Also no.  The selection owner may elect to provide a lower bound on the
size of the selection data when initializing INCR transfer, but the
requestor must be prepared for the owner to send transfer more data than
that.

> and then decide not to read it if it's too large?  That would also fit
> the spec of save-interprogram-paste-before-kill.

Once you start a selection transfer, it must complete 

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

That still contradicts my previous remark: Emacs should not place limits
on the _amount_ of data transferred in the first place (except perhaps
to avoid running out of VM) but allow the user to quit from long-running
operations instead.

Consider the case where selection data is being transferred from an
owner connected to the X server over a connection with very high
latency.  Waiting for a single quantum of selection data to become
available (usually 64k) may still take several seconds, during which no
data has been read.  Because of that, limiting the amount of selection
data transferred will have no effect on this delay.