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

Previous Next

Full log

View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: sbaugh <at> catern.com, 64423 <at> debbugs.gnu.org
Subject: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections
Date: Wed, 05 Jul 2023 20:50:34 -0400

Po Lu <luangruo <at> yahoo.com> writes:
> Spencer Baugh <sbaugh <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.