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 11:46:34 +0000 (UTC) Message-ID: <87mt0bq4py.fsf@catern.com> References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.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="15638"; 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 13:47:31 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 1qGeVG-0003n4-9T for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Jul 2023 13:47:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGeUq-0004kw-VF; Tue, 04 Jul 2023 07:47: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 1qGeUo-0004jH-JC for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 07: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 1qGeUo-0007Tu-AK for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 07:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGeUn-00012S-VS for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 07:47:01 -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 11: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.16884712043965 (code B ref 64423); Tue, 04 Jul 2023 11:47:01 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 11:46:44 +0000 Original-Received: from localhost ([127.0.0.1]:35111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGeUW-00011s-Bq for submit@debbugs.gnu.org; Tue, 04 Jul 2023 07:46:44 -0400 Original-Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:31492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGeUS-00011Z-SQ for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 07:46:42 -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=Y8Q+XLlcM9UD7sRJ40n/h6XFb6hnMG45/os2J3WU+40=; b=yRP3qEp4106qj4Sw0amAXD+lixa8sybplNcNjzQbvokf3d4aDwvE5TpepV+TxWOqyM4U zPFta61HpK4FFrIQVGBD7o+I/rqQ37B4WxU2QxkHP4oSHrxoFlgHRyhPT7KaLBsk3Wz2Wq 6ht9EkOAFnozjcYXyFVXCL49TRxMvFsgwfGrTm6D28TE1Nlp8P8Pi+N2A7aXsPH0EbJM42 km6IZ9NVQb3Hu++9eHi6I76l7ZqpOGH2CZvmzBoPA8Xa613vWsUZcOpCRGUMdmDSsuWUkS q6anbVDaNk1lQUpi5AezIawrfNZihCdM9cPAoQdAKPidVvnj6eDh+/1OQbGmn3Hw== Original-Received: by filterdrecv-d7bbbc8bf-nxr9l with SMTP id filterdrecv-d7bbbc8bf-nxr9l-1-64A4069A-13 2023-07-04 11:46:34.327030306 +0000 UTC m=+4709216.412763670 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-4 (SG) with ESMTP id xpOCG29AQy-E71kAazlngA Tue, 04 Jul 2023 11:46:34.202 +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 BB92660159; Tue, 4 Jul 2023 07:46:33 -0400 (EDT) In-Reply-To: <87y1jwqqel.fsf@yahoo.com> (Po Lu's message of "Tue, 04 Jul 2023 11:58:10 +0800") X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbIhZLy9DqN3P+8z5Q465AOKRAq9Cp89dNvmZ85DaxubXuCj7kvA7BiyIIEyzaH1x+29nvTKhcZwVQV3n2Cf5nsdMpwCtJLqbwT2MBKV4jw4nOcKJKDMdgjE2sYqmWolsTHTuyrYqurJVmX1FDzlY9I/vvAxDSmOWD19qiVhjjxPlQ== 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:264577 Archived-At: Po Lu writes: > sbaugh@catern.com writes: > >> 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? > > 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. >> 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"... > > It's an intentional omission: INCR data transfer is designed to work > even if the owner itself does not know much data will be sent. For > example, if the selection data is being transferred from a pipe or > socket. Ah, I see. Then, like pipes and sockets, it should really at least support interrupting the transfer... >> 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... > > It's straightforward in Emacs, since that's already how it responds to > selection requests from other clients. But it's a bad idea: what if the > user requests another conversion from the same selection owner while the > transfer is in progress? This is technically possible, but will need > Emacs to specify a different property in each ConvertSelection request, > which will lead to lots of needless InternAtom requests and round > trips... Such costs only need to be paid if there are indeed multiple conversions happening at the same time. In the common case there's just one, so there's no extra cost of adding the ability to have multiple ongoing conversions. Actually, how does this work today? If an Emacs user quits a conversion and then immediately starts a new one, that seems to work fine. We don't do different properties in each request. I realize the protocol doesn't support it, but doesn't that suggest that it's fine in practice to interrupt a conversion...? (Quitting a conversion then running another would be one way to have multiple conversions at the same time. Another way would be (related to my other thread about call-process) to allow running Lisp while an incremental selection transfer is ongoing. I know that seems useless but I really am of the opinion that every blocking operation in Emacs which can take more than a few milliseconds should support running Lisp while it blocks...) >> 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? > > Yes, because when the user choses to do so, it is already clear that > there is a problem with the selection owner. Transferring a lot of data > is not a capital offense, and Emacs shouldn't condemn the selection > owner just because it does. > >> 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! > > You mean, x-selection-timeout? Yes. Personally I'd like to have a lower value for that when a save-interprogram-paste-before-kill is triggered. So adding a separate save-interprogram-paste-before-kill-timeout which can be lower, and which let-binds x-selection-timeout, seems good.