From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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 08:40:27 +0800 Message-ID: <87jzvgse4k.fsf@yahoo.com> References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16681"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: sbaugh@catern.com, 64423@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 04 02:41:22 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 1qGU6c-0004CV-D0 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Jul 2023 02:41:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGU6K-0001oE-CO; Mon, 03 Jul 2023 20:41: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 1qGU6I-0001mW-Bi for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 20:41: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 1qGU6I-0001fL-26 for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 20:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGU6H-00030I-TP for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 20:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Jul 2023 00:41: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.168843124411515 (code B ref 64423); Tue, 04 Jul 2023 00:41:01 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 00:40:44 +0000 Original-Received: from localhost ([127.0.0.1]:34711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGU60-0002zf-9q for submit@debbugs.gnu.org; Mon, 03 Jul 2023 20:40:44 -0400 Original-Received: from sonic315-21.consmr.mail.ne1.yahoo.com ([66.163.190.147]:35910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGU5x-0002zP-Fv for 64423@debbugs.gnu.org; Mon, 03 Jul 2023 20:40:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688431234; bh=llawFD2YFamqdCmfYZ763WFXATQp/CPlCjSOx9dIJQc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=s3Gsq2dZXP4izRx8eT3urig8r/KzD+mV7nrslD3Is1+T6kPuuwYkkL4mn7oV5omKt2IQP5PcwkLYQyIKN7AYHg+y5MuLspKUKrq3o8cCureVlXXIeM1FF+LeFJXSYopM3ylpBmD9VZhNmxc9bD6PCvyijV92WxKYIUuuR8sVXQV0XwwaRqDj2BbG7FTRgjHvfNhH68SZOlaTe8LEhO7lOkJBCZ1T7pTOLrbsrshU0AdAgqoZSkcAi9DMxhHu77pFu1aVd1Ts3R6sdpyRgw+foa8VCsD97hkSH8KIUCpjRxQdqS5pmi+dnzL3fDa+fkh45hmn4GsaOIsMSEvi6HFERw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688431234; bh=IZQ0QDxVnm/tHBBD75CfhBdVR4TxhnIjGW5chw6Bd3H=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=CjJ0174gu8r1Gt2efU03U8LkGX69j6ryjTCVkHIuFZYOIBfG8v0GKNbSNtnX4BjM52x9ayw0uJL9kub0bmaMqQybiY/rhEV4Fsfo+aQ9DNq6O10g9mvx+E1R3TOEtkucooRPOs3iu7OmNA84l65ytq+hGVrMZrG1A8v9xp4kkZqQcshmwFQzxJ8ZrpTH0cijDRyT9IPFpZ9oGb/A27Ad0j7S10lKrrvQtxfkEwaqsczV3GuFylJN3hwKD76hJT8/8fwtG5+uXXkh3GrvjxLN2/Z/VNHC+IgRpE/UK12N5sIdTGF395iL34Eu9ifTZYSB6JG20scdGgrjIxw0TKNmqA== X-YMail-OSG: 4_NqlUEVM1n2iKMWKcm6iZTkFO7ZbBQGpMEb1jhEGIdV5dse6d8CL82KGt_fN7G fdMxqq_ra256cO2LGoO3PIRolVb0qc2bKI6n3KZAnh7OX.Rids.iAxp7niMrD0ZR5C2B.F4LgsRX 2R7KoATF1_cGH61mp5.4kSOc3zEmdGijBTYOwLPrcFZPAGVBCQJ8uGo4leHQC8.S3Pj3NGOEPQQZ 8efxNIzI.8tfkYh2fNAYlSjueyqt_gyeJXV3yvFYkV9Lyod2ATDZFjBmMQ8D_OhHpAyRnM31vdrv sjnUPRInFuG7eUPkB0oKbYSHW3Gmm4O6VbK1l3J1Hv7_I536XNTfwiBXYo51NalYkjWZjkI2kPpI xeKHIAQw295_0hllsXGH3MVqy7f0BpVhN4WLhD1jFsmWkZwbhgI_BeywaU6HaoLw0380SFUlI4GH i6zOEPvJgIZhXg.SG2KOweYKUfVkMpRfFhK6MDdmD9wwfgpJYxxhkHz6Vv4hEALP3cLsRd1n15OL roAVGYJMaD5aCAjwHaxFzbD_F81PA9Sxxyt155m1ylP7OO.6BphJUw0iyBa8HIIrE8.9elFhuRXa CZMLhPzVgBajfEwMb8s0hA2uy7xmM4eigR53kMBB8leD3rKibGh8CXduTbobwum9hgW5Dgjvc70R P43wtGTBmm9MLlHwxz6XHpU3FxFVNzOecBo8Q.gKSVkI8PBOh5B9EKcdk6exnh2JGHLIEGF5cTAV ofuu.5omE.CODn8i3jGmhzsHbRrVib2IOAZpj9AGz0CPBnIbR.LvqCegGz8cZEGOp3ms3mJfLVqO zFJZbIoHqTjqHo2dpMHwjhKzO2t7vgcRhyBaGYdUrM X-Sonic-MF: X-Sonic-ID: a24c6d93-2098-471c-ab61-ee4e3bc47bbb Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Tue, 4 Jul 2023 00:40:34 +0000 Original-Received: by hermes--production-sg3-67fd64777-ftxnx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b2f31679b5170b969fd0037d244c0e44; Tue, 04 Jul 2023 00:40:32 +0000 (UTC) In-Reply-To: (Spencer Baugh's message of "Mon, 03 Jul 2023 08:46:39 -0400") X-Mailer: WebService/1.1.21612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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:264555 Archived-At: 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. > 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 >> 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.