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

[sbaugh]

sbaugh@catern.com writes:
> Po Lu <luangruo@yahoo.com> writes:
>> sbaugh@catern.com writes:
>>
>>> Po Lu <luangruo@yahoo.com> writes:
>>>
>>>> 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.
>>>
>>> That would be a decent solution.  Although I'm not sure how we'd
>>> implement it.  We want to, somehow, know that after a selection-transfer
>>> has been aborted, we should not try to transfer that selection again.
>>> Is that something we can check?  Whether the selection has changed,
>>> without transferring it?
>>
>> Emacs will probably assert ownership of the selection after the kill
>> takes place, anyway, so there is no need.
>
> Good point!  So maybe if a quit arrives while we're reading the
> selection in kill-new, we should immediately take ownership of the
> selection.  With an condition-case, perhaps.
>
> Or... just ignore the quit.  If we're reading the selection in kill-new
> and there's a quit, just proceed to doing the kill.

Here is an implementation of that.  I think this is the right strategy
and I'm glad we discussed this, I think this will behave better for
users than my original suggestion, and this way doesn't require any
configuration.

>From b7b0feb879994696bdd6f6f4cc982779b1ff5b45 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@catern.com>
Date: Sat, 8 Jul 2023 12:36:22 -0400
Subject: [PATCH] Ignore quit while getting interprogram paste in kill-new

On X, if the current selection owner is not responding to selection
requests, the user may want to take ownership of the selection.  The
obvious way to do this is to kill some text (which a user might also
be doing just as part of normal editing at the time the selection
owner becomes nonresponsive).  However, if
save-interprogram-paste-before-kill is non-nil, then killing text will
hang until the user quits, and this quit will abort the entire
kill-new, preventing the user from taking ownership of the selection.

Now instead if the user quits while we are attempting to retrieve the
selection from hanging owner, we will proceed to take ownership of the
selection as normal, resolving the problem.

(One example of a selction owner that might not be responding to
selection requests is another instance of Emacs itself; while Emacs is
blocked in call-process or Lisp execution, it currently does not
respond to selection requests.)

* lisp/simple.el (kill-new): Ignore quit while getting interprogram
paste (bug#64423)
---
 lisp/simple.el | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lisp/simple.el b/lisp/simple.el
index 26944f1f72d..95d00cc506b 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5618,8 +5618,10 @@ kill-new
       (if (fboundp 'menu-bar-update-yank-menu)
          (menu-bar-update-yank-menu string (and replace (car kill-ring)))))
     (when save-interprogram-paste-before-kill
-      (let ((interprogram-paste (and interprogram-paste-function
-                                     (funcall interprogram-paste-function))))
+      (let ((interprogram-paste
+             (ignore-error 'quit
+               (and interprogram-paste-function
+                    (funcall interprogram-paste-function)))))
         (when interprogram-paste
           (setq interprogram-paste
                 (if (listp interprogram-paste)
-- 
2.41.0