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 11:58:10 +0800 Message-ID: <87y1jwqqel.fsf@yahoo.com> References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.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="5466"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Spencer Baugh , 64423@debbugs.gnu.org To: sbaugh@catern.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 04 05:59:25 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 1qGXCH-0001Fz-Cn for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Jul 2023 05:59:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGXBw-0006YL-3i; Mon, 03 Jul 2023 23:59: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 1qGXBu-0006Y9-OQ for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 23:59: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 1qGXBu-0007VQ-BP for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 23:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGXBt-0008K1-Ra for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 23:59: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 03:59: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.168844311431950 (code B ref 64423); Tue, 04 Jul 2023 03:59:01 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 03:58:34 +0000 Original-Received: from localhost ([127.0.0.1]:34817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGXBS-0008JF-6w for submit@debbugs.gnu.org; Mon, 03 Jul 2023 23:58:34 -0400 Original-Received: from sonic303-20.consmr.mail.ne1.yahoo.com ([66.163.188.146]:43583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGXBM-0008Iw-8k for 64423@debbugs.gnu.org; Mon, 03 Jul 2023 23:58:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688443101; bh=tJttuuOweKhw6HPBWbXoNORY7tz3eCQcZDDR6PGIhrM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=k5+o1NFLNDI66Upq40bvP4h2m3cNHRsYs1V1NSQ3uDd+yNStvaNwjhSvX5UdH/V7A4iGqF2vE7H86YANobGw2zzb9Izaknd12TYNF1eamZMEodxGVTGvdjKxUIY830EadLa97a7y20ZhyyO90/LnwtjYYMEjv9MvvqWTsROcC7Ks77GsdN2rUZcLSGgNs6PK1f0aWtcT512yUOj7UVfRztGZoqbj6caoHazSxS/SmOos75ne+RF0YhpDMKTwGJJxUjZyoOyIt2Pd1pbHdw5GPAmw3hv+roM/6IHOQhVezHe+0zuhpqqwnY0q8hL/5Bnr/tvAq/Vu32aL7v8uxBYP/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688443101; bh=AC1yecRXm5XVyWaIdmGkapKuSLk5yuX0x4JweiSUYa8=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=sV1Z530bRolLAOYOCULk0380jCOi+H/E5bE2q1hsRoxQvFABYad5D85Evd1Rpig5cEt+gHITWQ6Af72r+UiV9omu745M7X4W8DLJm6yzwdqHb4LjC0HDnXCPv2xfbKUsYHABh3De30yCxVqYc7hAEaqCmEGH9zZ13buYYg/kh0NCY1wUUgcLN9SnmXM6LzQ05aNt2HNFWMCvOxM8aPWZYuqC2ilVvEK/OkljdL+Yzi7KlqwQ7K6hGa+Ou0xZMA2fumN7Dt7X4G9OeRNgpGCsN1ZmWeQ6wHtvMyzZcW0WWdXBg7b1wcouR/8DXVhCmtigTfBAmDhWb7vn95hFwff+Zg== X-YMail-OSG: aqNLQ0AVM1k1SQpfFHbNvvep6gYfPDel99BTliOfETfEg02YaU5oO4_6qOCBiCT N_liubUKPV6cPs.A9FzfBlNy4eioBQFXRgR48CF8jHM_z2N4uPReaHTF2ZE0lC0vPAJAgLmVhCMz tVWf2fJiLjLt7CTbqiWZw_97AM.Dd9dx15LEccJg675C5tW0lAxXLwfBV5riDNV8giZ4mBC.2yNc GMBLvrZ7zLqLPfvJw6kJ9b9_5SPZ_Za8U4SIyl4FADl3Wb4cOqzr7BizObBL86SBZEPuXZLGvzIq SoW7Rzq_bj77zkgMKmpOBNZ_xFXjNl1yDdZdVKu77yzRbHoa2KtWaAzYOcZmxDLagTDzu5J2Cq62 _05B43i5ADFFh_HIXxNEdtCxXNbidgGt8qlpopRANm9vqI3wXZUJ_1zsjTvjdL1xpU4nQOoANqTW VbWXM9jdP413IbwUeuhPz.fqdk2J2uTi7.3EMzxZ3VvkFYvUiPooyl8scbXuKcGOy9fIV1S9qqeZ 5j6z3fx9Qt1nS8W4m1e3g17uLeMP2.3yaEl3S0I7ZnPojGx62q8C4g3Px2uZmnXSGIFkDBeyBzRQ sFvQ9WvO_g5VHHon3NMshSN0EULndiVUB9dj2hO2ThJXFz.OBenmtum.7xE6OELagU6gnLrZOE.w f29pvBY3u2g08MevUDNlO6yCNZ0m3LzDgNv1ppOBr1fV94DRDLjRIUtPeaUlS8jP8zdegXlFBnUE w_ifjzzLsTagYZQJDjw7p2KsuCqxRLCY0ezKve1LaSpxXQB3HAIo__m2V0oxnQ35nZGKToTudGNO kXHuKUm_FmQ7SMhtcqa81xnm5D0Blg6PNFDK5gaZYZ X-Sonic-MF: X-Sonic-ID: 6967b7bd-8d1d-414a-9cf8-0b2fc46b4994 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Tue, 4 Jul 2023 03:58:21 +0000 Original-Received: by hermes--production-sg3-67fd64777-bps25 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 710eba99a3ff08195bed742fd49e84bb; Tue, 04 Jul 2023 03:58:15 +0000 (UTC) In-Reply-To: <87pm58phyu.fsf@catern.com> (sbaugh@catern.com's message of "Tue, 04 Jul 2023 01:45:46 +0000 (UTC)") 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:264561 Archived-At: 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. > 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. > 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... > 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?