From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.bugs Subject: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections Date: Tue, 04 Jul 2023 01:45:46 +0000 (UTC) Message-ID: <87pm58phyu.fsf@catern.com> References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18295"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Spencer Baugh , 64423@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 04 03:46:29 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 1qGV7b-0004WI-SF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Jul 2023 03:46:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGV7K-0004LI-9v; Mon, 03 Jul 2023 21:46:10 -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 1qGV7D-0004JR-Bd for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 21:46:03 -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 1qGV7D-0001C7-3X for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 21:46:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGV7C-0004e9-HP for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 21:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Jul 2023 01:46:02 +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.168843515917850 (code B ref 64423); Tue, 04 Jul 2023 01:46:02 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 01:45:59 +0000 Original-Received: from localhost ([127.0.0.1]:34738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGV78-0004dq-SG for submit@debbugs.gnu.org; Mon, 03 Jul 2023 21:45:59 -0400 Original-Received: from s.wrqvtzvf.outbound-mail.sendgrid.net ([149.72.126.143]:45394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGV73-0004dW-0V for 64423@debbugs.gnu.org; Mon, 03 Jul 2023 21:45:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=yvaYKSlayjj3kqGPa3sXl691d/SA4M65cHZRxBdoHE0=; b=KZAPHf7C/1s7EPOULGgua8ZGMEyoRWMiD5+WBCvZysSU7zcus5PrbDo3PzaZ4m8eoHMu cn0ErpSAtFVoC99RlaUxPbrb+w3rb/aBZl7NUU2Hs6iAMvl20xnLSiqm5lgUM1WFl8qib1 JsYQ+p0iNUiTudkEdgyA2wTPHeop4Dzyz1N2m/Kd+rgLhjMlM22HkIsBExYW4sBpHVOVfv YsBMYUHIp1rtcaCqBuZtTUGk0Rx8lH+ggo+WCShxpA9TmMEZyuKtXOsQ0F+oakRhcz8r9e ta7gc2yAGk0qu7zUgd3f2FfxIGXrFFsVxNbECy9RV/A1u98rfUaQwAWOyhkQUoYQ== Original-Received: by filterdrecv-84b96456cb-zd4xh with SMTP id filterdrecv-84b96456cb-zd4xh-1-64A379CA-12 2023-07-04 01:45:46.523542068 +0000 UTC m=+4673253.148329174 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-28 (SG) with ESMTP id x3t0WA1bTDCj7DbffsQ9ig Tue, 04 Jul 2023 01:45:46.347 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=yahoo.com Original-Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id C7E736001E; Mon, 3 Jul 2023 21:45:45 -0400 (EDT) In-Reply-To: <87jzvgse4k.fsf@yahoo.com> (Po Lu's message of "Tue, 04 Jul 2023 08:40:27 +0800") X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbJ5RixDol/oIg2WQiR+OpJEuX3hIEIAAUeNzTT40aqOZX2fo2RZ5L2CkzPOcF0tmhs6XMy3da1nl9Yd1o5gggw0/iB3MYhgtkhrBWB6DgSp+i+VlpzNNTLhENOLMNfW2Kjj4bz2UKf+fMaZLX/j2XbapBmcz6CMNPYKZQFlwUkFHw== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== 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:264559 Archived-At: Po Lu writes: > Spencer Baugh 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? >> Is there really no way to avoid a large data transfer in ICCCM? > > There is none. > >> Is there some way to learn the size of the selection in advance > > Also no. The selection owner may elect to provide a lower bound on the > size of the selection data when initializing INCR transfer, but the > requestor must be prepared for the owner to send transfer more data than > that. > >> and then decide not to read it if it's too large? That would also fit >> the spec of save-interprogram-paste-before-kill. > > Once you start a selection transfer, it must complete That is unfortunate. That seems like a terrible omission... An important network protocol principle is "tell the client up front how much data you are going to send"... Anyway, there's still a possible solution: we could return control to the user if the transfer is too large, and continue with the INCR transfer in the background, just to satisfy this ICCCM requirement, discarding the data as we receive it. This would be straightforward in a program with a normal event loop, but might be difficult in Emacs... >>> 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. > > That still contradicts my previous remark: Emacs should not place limits > on the _amount_ of data transferred in the first place (except perhaps > to avoid running out of VM) but allow the user to quit from long-running > operations instead. > > Consider the case where selection data is being transferred from an > owner connected to the X server over a connection with very high > latency. Waiting for a single quantum of selection data to become > available (usually 64k) may still take several seconds, during which no > data has been read. Because of that, limiting the amount of selection > data transferred will have no effect on this delay. If the round-trip latency is 500ms, then waiting for the first quantum of selection data will take at least 500ms, yes. Subsequent quanta will also take at least 500ms each. If the selection is large, there may be many. If there are 20, then kill-new will take 10 seconds. But if we can limit the amount of selection data transferred, kill-new will only take 500ms. Wait... am I missing something? You're saying it's okay for the user to interactively choose to interrupt an INCR transfer, even though that will leave things in a bad state? Couldn't we just do the same thing in code, then? Can we wrap a user-customizable with-timeout around gui-get-selection? I actually agree now: limiting the amount of data transferred makes no sense for user experience. But limiting the *time spent* transferring data makes total sense! Users are able to do that today: We should allow users to automate that! So I think some new save-interprogram-paste-before-kill-timeout variable would work perfectly. All it would do is something users are already capable of doing, but without aborting the entire kill-new operation. That seems perfect!