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 21:19:51 +0800 Message-ID: <87h6qjreyw.fsf@yahoo.com> References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.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="10143"; 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 15:21:28 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 1qGfy8-0002Cs-CE for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Jul 2023 15:21:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGfxo-0002qr-BP; Tue, 04 Jul 2023 09:21: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 1qGfxm-0002qC-5P for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 09:21: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 1qGfxl-0007ew-TI for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 09:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGfxl-0003XW-Oo for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 09:21: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 13:21: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.168847681713528 (code B ref 64423); Tue, 04 Jul 2023 13:21:01 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 13:20:17 +0000 Original-Received: from localhost ([127.0.0.1]:35169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGfx3-0003W8-6y for submit@debbugs.gnu.org; Tue, 04 Jul 2023 09:20:17 -0400 Original-Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]:33422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGfx0-0003Vo-By for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 09:20:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688476807; bh=Zk9TIpP9pSvYR5zQT+REqmq0xEjVBeFcsgr8bXXGV2Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=txkboh9vQtTISk1/vuDApX4MiSGBKZY99qWoXbUq97+6duZza3FRNTfh8mXLb2rIkOUTyssVND17q/hFYlGLkyY4Igvxqm7fq/+3MTwPuh6ltjoCIhq0u39TiXEeAujmY/nJprEs2XDDiCflUIF5+vK+yRrXfuZO9HcT7LTYZoqprSok4fBSkMFdJRFbb7LutWFqkptqlyRKd30mCmlKDVw9NTSWY7ytD1IRPWBSArayohAPGRhI1jOPlH5ldoP03oPxo2Mkb5CkmOgf6TqPPvnRYMeMmXGZtNDPhwx6eyr+FKzGmKVh1UpRba0zzK5GSnk6mKYM5hx4jud2/RO3DQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688476807; bh=DUaZX0v70QhGRZaHR/GaBz0grUtVIb54QYDiZzbiur9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=rgc5bNLngmGxrRD4JWp0TVb05bRnlyioGg2LYmQ56ai/N+ihCzmiOcMu1wD8DnMoj3O/B3y5Ch5e/0EKXhrFuEDfg8nBRtmeoFUy+KxdOIt5yif/JYHwL8FydU2GhUdcYFl7Z31bvf3n+BN20j6vZ6uSDMl4L5OGc8Tck70J3qeswLo2Qk5a+n35PStU3CMAwvAKv3icMZiQ7vbALEPqK/yfDYkRVfcnyWvpm84WYjedczKtISPBgcfgcHIkACF7TgR5XizYf0xnZOKeuIvyMKY1EhUMTpNYLXG5eeSbS6EYSrXj1XcFbEcj+zczoiZzCIBURsDbujnb0ZMQIoxYIw== X-YMail-OSG: EpLjIyIVM1k66PHetsZmafRxrE0hUEI.4GZ2XbOpeg3ndL44mim94dzB3tJWBec FwNPwoWLVqTMDIkJn3QO7DwA5baa.3LpY1WT7Ob6j9gDSIPHxuKft5Tb987ZdQ7rYcn2sDk9.w4e mP7gg.A0F0G4NKXBU7eFg.HO6OCfTbPuZ53xz.VF3ahXyvt2EkQqFdaUu0_8IgRDLY_VXqOMH8Mh nQz0Ivc_RaSLcmfuLPkgQZL9cYAD9adCjEM8WRXOvgxHVEwN9o80SAMcH5PKN9QcmEWkF2ouM6KE eQy9wTR3_18B_JGxYpMFNAdHC77XoEac7GRhLgMo2OkKFxEeftWR6gNzZX_YNpA3QsVwI2eY9jv8 KnOQ5QqGnSHo1GgflKaZw3wve5t1KEY3eqAZW3xGYTDBJ3gNgNqT5qcFQOkSF4JSNcIce8uUUJPD DbBPwiFBEf6KZdiikpQGYUf3.2Gy1km5u8uMoV4Gz6_L.geFSFOIWMvIPgJb.ki1Icm1d627QT4u wNvPwrT9nodh3co076ipYmAx9B_7az1RkCmn9I4LZAPqcl1cTA_25e42TZxl0Ki1ixWVo3S11nyk 3JN_l8X5XG5Y.XTx44221aaJ5Vjup_AxzDaVTQQumEIY.o_0TwQpTRrXRzRE8jVoWjhAOhGpEnig E1LSiEM6Cm08823iS1wCsBZLk.r.4JjbotQtvxz5H6kV8gA50rfV.uoOwB.d.PYOwvCagssHnLgj GCT0Lr.2ABlcObtEH9F19JpYDLgwxqS84wcP3Gv94RmX4qzPurP4UULn0OufRQ9rotWVnpW8P2Ew cAYYtxIXXu8.EaLMxFu2N68DLlJlY3IJgTPRJVUPQk X-Sonic-MF: X-Sonic-ID: f7351589-29e5-46d6-9209-2d9ac8542b11 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 4 Jul 2023 13:20:07 +0000 Original-Received: by hermes--production-sg3-67fd64777-rc8tr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f06502479f5f681561df9d89ec264d8f; Tue, 04 Jul 2023 13:20:02 +0000 (UTC) In-Reply-To: <87mt0bq4py.fsf@catern.com> (sbaugh@catern.com's message of "Tue, 04 Jul 2023 11:46:34 +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:264579 Archived-At: sbaugh@catern.com writes: > Ah, I see. Then, like pipes and sockets, it should really at least > support interrupting the transfer... It's 30 years too late for changes to the ICCCM. So we will have to make the best out of what we have. > 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. Adding extra round trip cost to a part of Emacs that is already one of the slowest and most synchronous components of the X Windows support is unacceptable in my book. Especially for such an uncommon situation: I can't remember the last time I quit a selection request to a working selection owner, and I use Emacs over wide area networks every day. > 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...? If Emacs quits while waiting for a property change to take place, and the property change event from the recipient of the request that was quit still arrives, Emacs will become confused and return outdated selection data. Or even worse, a mixture of the selection data from both the new and old owners. Selection owners that are not implemented robustly may also freeze if Emacs quits before removing the selection transfer property from its window to acknowledge the selection data's arrival. > (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...) No, it's only necessary for us to ensure that C-g works, so the user can always quit from the long-running operation. Otherwise, your position cannot be consistent without insisting that constructs such as `while' also check for and run timers and selection converters. > 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. How is that different from setting `x-selection-timeout'? IOW, what's your real-world use case for such an additional option? Have you tried adjusting `x-selection-timeout' for all selection transfers? Let's not overengineer the system independent interprogram code with X-specific options. Thanks.