unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: sbaugh@catern.com
To: Po Lu <luangruo@yahoo.com>
Cc: Spencer Baugh <sbaugh@janestreet.com>, 64423@debbugs.gnu.org
Subject: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections
Date: Sat, 08 Jul 2023 16:39:00 +0000 (UTC)	[thread overview]
Message-ID: <87mt06mk7w.fsf@catern.com> (raw)
In-Reply-To: <87mt0bq4py.fsf@catern.com> (sbaugh@catern.com's message of "Tue,  04 Jul 2023 11:46:34 +0000 (UTC)")

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ignore-quit-while-getting-interprogram-paste-in-kill.patch --]
[-- Type: text/x-patch, Size: 2107 bytes --]

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


  parent reply	other threads:[~2023-07-08 16:39 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-02 14:13 bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections sbaugh
2023-07-03  2:35 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-03 12:46   ` Spencer Baugh
2023-07-04  0:40     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-04  1:45       ` sbaugh
2023-07-04  3:58         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-04 11:46           ` sbaugh
2023-07-04 13:19             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-04 14:46               ` sbaugh
2023-07-04 16:18                 ` Eli Zaretskii
2023-07-04 16:32                   ` Ihor Radchenko
2023-07-04 16:41                     ` Eli Zaretskii
2023-07-04 16:48                   ` sbaugh
2023-07-04 17:02                     ` Eli Zaretskii
2023-07-04 17:14                       ` Ihor Radchenko
2023-07-04 17:30                         ` Eli Zaretskii
2023-07-04 17:35                           ` Ihor Radchenko
2023-07-05  0:30                           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-05  2:29                             ` Eli Zaretskii
2023-07-05  3:51                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-05 11:27                                 ` Eli Zaretskii
2023-07-05  0:19                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-05 13:59                   ` Spencer Baugh
2023-07-06  0:12                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-06  0:50                       ` Spencer Baugh
2023-07-06  1:59                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-08 16:39             ` sbaugh [this message]
2023-07-08 16:48               ` Eli Zaretskii
2023-07-08 17:07                 ` Spencer Baugh
2023-07-08 17:49                   ` Eli Zaretskii
2023-07-09  0:39                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-09  6:10                       ` Eli Zaretskii
2023-07-09  6:12                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-09  6:46                           ` Eli Zaretskii
2023-07-12 19:18                             ` sbaugh
2023-07-13  0:32                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-13  4:48                               ` Eli Zaretskii
2023-07-13 16:17                                 ` sbaugh
2023-07-13 18:39                                   ` Eli Zaretskii
2023-07-13 22:39                                     ` sbaugh
2023-07-15  8:31                                       ` Eli Zaretskii
2023-07-15  8:33                                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-15  9:01                                           ` Eli Zaretskii
2023-07-15  9:35                                             ` Eli Zaretskii
2023-07-15 17:38                                               ` sbaugh
2023-07-15 19:12                                                 ` Eli Zaretskii
2023-07-15 21:00                                                   ` Spencer Baugh
2023-07-17 16:43 ` Mattias Engdegård
2023-08-03 15:53 ` Spencer Baugh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mt06mk7w.fsf@catern.com \
    --to=sbaugh@catern.com \
    --cc=64423@debbugs.gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).