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

Previous Next

Full log

Message #71 received at 64423 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't
 prevent streaming large selections
Date: Wed, 05 Jul 2023 09:59:53 -0400

Po Lu <luangruo <at> yahoo.com> writes:

> sbaugh <at> catern.com writes:
>
>> I think you might be misunderstanding me?  Just to say again, in the
>> normal case, this would not add extra cost.  This would only add extra
>> round trip cost in cases which, as you say below, currently just confuse
>> and break Emacs.
>
> It is extra cost, for an insignificant problem whose fix is unwarranted.

The insignificant problem is Emacs potentially getting the wrong
selection if we interrupt an incremental selection transfer?

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.

>> (Also, the entire point would be that this component would move from
>> being synchronous to being able to run in the background, concurrent
>> with other things.)
>
> No, setting up the selection transfer will still remain synchronous, and
> x-get-selection-internal will continue to block.
>
>> This is becoming tangential, but, yes, I will bite that bullet.  "while"
>> should also check for and run timers and selection converters, when Lisp
>> code opts-in to that behavior.  I can think of several ways to implement
>> this without hurting performance.
>
> That's unsafe, and that's simply not how Emacs works.  You're talking
> about turning code utilizing while into signal handlers with strict
> reentrancy requirements.
>
>> IMO the major issue with the Emacs UI at the moment is that it blocks
>> too much, relative to "modern" applications.  Some of this blocking can
>> only be fixed by speeding up Lisp execution, but substantial parts of
>> this blocking can only be fixed by making Emacs more concurrent - that
>> is, making it possible for Lisp code to run concurrently with other Lisp
>> code, on an opt-in basis, instead of blocking all Lisp execution while
>> operations like gui-get-selection and call-process are running.
>
> Other UI toolkits also block waiting for selection data to arrive.  They
> even block when responding to selection requests, while Emacs can
> respond to multiple outstanding selection requests simultaneously.

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.

>> Here is the real-world use case: When I yank I'm willing to wait for 2
>> or 10 seconds for the paste to complete, since the paste is what I
>> actually want.  But when I kill-new I want to wait less time, because
>> the save-interprogram-paste-before-kill behavior is just a nice-to-have,
>> which I want to happen if it's convenient and fast, not the actual thing
>> I want to do.
>
> Have you actually tried setting just `x-selection-timeout' and found it
> unsatisfactory?

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.

Previous Next

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