On Jul 8, 2023 13:49, Eli Zaretskii <eliz@gnu.org> wrote:
> 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.
I'll defer to Po Lu on the best way to do that, since I suspect the simplest way - just wrapping it in a check on window-system - is not what we would want to do