From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections Date: Wed, 05 Jul 2023 20:50:34 -0400 Message-ID: References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <871qhnqkfg.fsf@yahoo.com> <87ttuhnbil.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3083"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: sbaugh@catern.com, 64423@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 06 02:51:26 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qHDDS-0000dz-Dw for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Jul 2023 02:51:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHDD6-0006fY-Cg; Wed, 05 Jul 2023 20:51:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHDD4-0006fJ-Mp for bug-gnu-emacs@gnu.org; Wed, 05 Jul 2023 20:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qHDD4-0006c9-ED for bug-gnu-emacs@gnu.org; Wed, 05 Jul 2023 20:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qHDD3-00027V-Oe for bug-gnu-emacs@gnu.org; Wed, 05 Jul 2023 20:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Jul 2023 00:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64423 X-GNU-PR-Package: emacs Original-Received: via spool by 64423-submit@debbugs.gnu.org id=B64423.16886046428123 (code B ref 64423); Thu, 06 Jul 2023 00:51:01 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 6 Jul 2023 00:50:42 +0000 Original-Received: from localhost ([127.0.0.1]:39153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHDCj-00026w-Nm for submit@debbugs.gnu.org; Wed, 05 Jul 2023 20:50:42 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:58635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHDCh-00026j-QZ for 64423@debbugs.gnu.org; Wed, 05 Jul 2023 20:50:40 -0400 In-Reply-To: <87ttuhnbil.fsf@yahoo.com> (Po Lu's message of "Thu, 06 Jul 2023 08:12:34 +0800") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264648 Archived-At: Po Lu writes: > Spencer Baugh writes: > >> The insignificant problem is Emacs potentially getting the wrong >> selection if we interrupt an incremental selection transfer? > > Yes, when the user does so deliberately. > >> I'm confused, it seems like that contradicts what you said earlier. >> >> If interrupting an incremental selection transfer is an insignificant >> problem, then there should be no obstacle to automatically interrupting >> the incremental selection transfer if it's too large. > > Interrupting incremental selection transfer _automatically_ is a > significant problem, because Emacs cannot judge if the selection owner > is functioning normally. If the user quits, he has determined that it > is not, so it is acceptable for Emacs to terminate the transfer there > and then without considering the consequences to the selection owner and > future selection transfers. And yet, we do this today: that's what x-selection-timeout does. Should we remove that functionality? I assume we should not remove that functionality. So if automatically interrupting a selection transfer if the owner takes too long is fine, what's the issue with interrupting it if the owner sends too much data? Both situations are usually the result of buggy X clients, both situations would break Emacs if not handled, both situations are standard considerations for robustness in any network protocol. >> OK, so we are doing at least as good as other toolkits when it comes to >> retrieving the selection. But at my site the UX is still worse than >> other applications because save-interprogram-paste-before-kill makes >> taking ownership of the selection block, while for other applications it >> does not. And save-interprogram-paste-before-kill is a useful feature, >> and I want to make it work. > > Other programs do not have a kill ring at all. Yes. And Emacs does, so it needs to do more work than other applications to make to work correctly. >> Yes. x-selection-timeout is configured to 5 seconds for every user at >> my site. They still find it unexpected and complain when killing takes >> that long. > > But do they complain about inserting the contents of the selection > also taking too long? Or when a program other than Emacs blocks for > more than 5 seconds upon Button2 or Ctrl+V? No, because then they are performing an operation which it makes sense might block: pasting data copied from another application. In that situation, they are fine with it. > Anyway, this points to a problem with an X client at your site and not a > problem with Emacs. No, there is no problem with other X clients. It is simply that users expect delays when yanking and don't expect delays when killing. So, Emacs should be able to configure a different x-selection-timeout when running the save-interprogram-paste-before-kill logic, to reflect the fact that users have these different expectations for yanking and killing. I don't see why this is objectionable.