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

[sbaugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: sbaugh@catern.com
>> Date: Thu, 13 Jul 2023 16:17:32 +0000 (UTC)
>> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org
>> 
>> > You can do it in a way that is not objectionable to either of us.  It
>> > is very simple: make the changes conditioned on X.
>> 
>> OK, how about this?
>> 
>> modified   lisp/simple.el
>> @@ -5618,8 +5618,11 @@ 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
>> +             (and interprogram-paste-function
>> +                  (if (eq (window-system) 'x)
>> +                      (ignore-error 'quit (funcall 
>> interprogram-paste-function))
>> +                    (funcall interprogram-paste-function)))))
>>          (when interprogram-paste
>>            (setq interprogram-paste
>>                  (if (listp interprogram-paste)
>
> Fine by me, but please add a comment there explaining why we do that
> on X.
>
> Thanks.

OK, comment added, here's the patch.

>From 4d669af4c6273d5c7ca229353c5056e3969f84ae 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 | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/lisp/simple.el b/lisp/simple.el
index 26944f1f72d..b97b5dd1725 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5618,8 +5618,14 @@ 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
+             (and interprogram-paste-function
+                  ;; On X, the selection owner might be slow, so the user might
+                  ;; interrupt this. If they interrupt it, we want to continue
+                  ;; so we become selection owner, so this doesn't stay slow.
+                  (if (eq (window-system) 'x)
+                      (ignore-error 'quit (funcall 
interprogram-paste-function))
+                    (funcall interprogram-paste-function)))))
         (when interprogram-paste
           (setq interprogram-paste
                 (if (listp interprogram-paste)
-- 
2.41.0