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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: sbaugh@catern.com,  luangruo@yahoo.com,  64423@debbugs.gnu.org
>> Date: Sat, 08 Jul 2023 13:07:37 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >> Cc: Spencer Baugh <sbaugh@janestreet.com>, 64423@debbugs.gnu.org
>> >> From: sbaugh@catern.com
>> >> Date: Sat, 08 Jul 2023 16:39:00 +0000 (UTC)
>> >> 
>> >> 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)
>> >
>> > Are you sure this is TRT for all the implementations of GUI
>> > selections?  AFAIU, the discussion was only about X.
>> 
>> Independent of that discussion, I think this change should be harmless.
>
> How do you know that?  The prudent thing in Emacs is to "do no harm",
> i.e. try hard not to affect any code that is unrelated to the problem.
> Assuming that a change is harmless is a mother of all bugs.
>
>> The worst thing that this change can cause is that a call to kill-new
>> can complete successfully when it otherwise would have failed.
>
> No, I think you can also do the reverse.  And anyway, this kind of
> "reasoning" is what gets us in trouble time and again.  Why risk all
> those potential problems, where the original issue doesn't exist in
> the first place?
>
>> But, also, I believe the discussion makes sense for platforms besides X:
>> if there's a bug in the current owner of the clipboard, then taking
>> ownership of the clipboard in Emacs will let us avoid that bug.  And
>> this change to ignore quits will allow the user to take ownership of the
>> selection in that way, whereas they previously would not be able to
>> (without manually writing some Lisp anyway).
>
> You do realize that some window systems Emacs support have no notion
> of "clipboard ownership" or "selection ownership" whatsoever?
>
> So please modify the patch to affect only X, TIA.

It's impossible to quit from selection transfers in other window systems
anyway, except perhaps PGTK when the toolkit is feeling generous.