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: Mon, 03 Jul 2023 08:46:39 -0400 Message-ID: References: <875y72ieq8.fsf@catern.com> <87cz193eno.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="28913"; 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 Mon Jul 03 14:47:24 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 1qGIxf-0007Iq-Ih for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 Jul 2023 14:47:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGIxT-0006oJ-2l; Mon, 03 Jul 2023 08:47:11 -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 1qGIxK-0006o3-Ja for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 08:47: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 1qGIxK-0007df-9N for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 08:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGIxJ-00006a-Vc for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 08:47: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: Mon, 03 Jul 2023 12:47: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.1688388407379 (code B ref 64423); Mon, 03 Jul 2023 12:47:01 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 3 Jul 2023 12:46:47 +0000 Original-Received: from localhost ([127.0.0.1]:33454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGIx5-000062-9O for submit@debbugs.gnu.org; Mon, 03 Jul 2023 08:46:47 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:55933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGIx3-00005p-4Q for 64423@debbugs.gnu.org; Mon, 03 Jul 2023 08:46:45 -0400 In-Reply-To: <87cz193eno.fsf@yahoo.com> (Po Lu's message of "Mon, 03 Jul 2023 10:35:55 +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:264523 Archived-At: Po Lu writes: > sbaugh@catern.com writes: > >> 1. emacs -Q under X, preferably X forwarded over ssh to make things slower. >> 2. (setq save-interprogram-paste-before-kill 2000) (or any other integer) >> 3. Copy some very large data in another X client, so the selection is >> very large. >> 4. (kill-new "foo") >> 5. Observe Emacs hanging as it receives the entire large data from the >> selection owner, and then after receiving it all, discards it because >> it's more than 2000 bytes. >> >> Solution: receive_incremental_selection in xselect.c should support a >> cap on the size of the selection it receives and truncate (or discard, >> returning nil?) the selection if it's larger than that. And setting >> save-interprogram-paste-before-kill to a numeric value should activate >> this cap. > > This is not a bug because you can quit while Emacs is waiting for > selection data to arrive from the owner. 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. > The ICCCM provides no means for the requestor to terminate an > incremental selection transfer before it completes, and owners may > become confused if Emacs abruptly stops responding to their property > changes while a transfer is in progress. Is there really no way to avoid a large data transfer in ICCCM? Is there some way to learn the size of the selection in advance and then decide not to read it if it's too large? That would also fit the spec of save-interprogram-paste-before-kill. > Emacs should avoid doing so unless the user explicitly quits (pointing > to a problem with the selection owner anyway.) > > Additionally, the way we deal with potentially long-running data > transfer operations in Emacs is not to apply a limit on the size of > the data being transferred, but to make quitting possible within those > transfers. What may be slow for you can in fact be perfectly > acceptable for others who are connected to their X servers through > faster connections. Yes, that's why this is a customizable setting rather than hard-coded.