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:

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

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

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

>> Let's not overengineer the system independent interprogram code with
>> X-specific options.  Thanks.
>
> A gui-selection-timeout would be fine with me, too.  Maybe other systems
> would benefit?  pgtk?

No other window systems will benefit from this arrangement, because
their selection transfer mechanisms are not interruptable.

`pgtk-selection-timeout' exists as lip service to the GDK selection
mechanism and doesn't actually work on Wayland.