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: Wed, 05 Jul 2023 08:19:31 +0800 Message-ID: <871qhnqkfg.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> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.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="3358"; 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 Wed Jul 05 02:20:23 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 1qGqFq-0000fe-Ug for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Jul 2023 02:20:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGqFb-0001ib-I8; Tue, 04 Jul 2023 20:20:07 -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 1qGqFX-0001iR-LQ for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 20:20: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 1qGqFW-00052D-Ds for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 20:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGqFW-0007W2-8e for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 20:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Jul 2023 00:20: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.168851639228865 (code B ref 64423); Wed, 05 Jul 2023 00:20:02 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 5 Jul 2023 00:19:52 +0000 Original-Received: from localhost ([127.0.0.1]:36830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGqFL-0007VU-Ns for submit@debbugs.gnu.org; Tue, 04 Jul 2023 20:19:52 -0400 Original-Received: from sonic312-25.consmr.mail.ne1.yahoo.com ([66.163.191.206]:34034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGqFJ-0007VG-J3 for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 20:19:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688516383; bh=DdHFKryQ/ArOwaMRbmAFpDltxkSE1Plgor7n9xgWkqU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=eQ9xl7L4x9jzlU0CJ4L4fTeuShp7a71o4NeLOtL0hVfprZrZlrgTSsIu+1urDE/85AZGt2hGHwbAFkI01qxUwyXx6xMxUQFe61gTBb/0wG5YIC3kBcYA6bgr9U27amuIjAcKY4N7v8jERy2WexGJMLwBaoH2giyDx8peVAB8H4Hq2fAHUrWxzz+avCYio91F0m1H9t5hhXPUegUXOQNbsZpj5KZmw6HDgMdeTgmZL5ZJd/ZfvxQdnpelddNlQ0hfJpC7BPU3fOogxAgmz+oh9VzoZAK/BsgvfZecguKjLKbuSfFrP8VimZVTfb6swdLMWAS2bSDcsp0/a3omaRM0DA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688516383; bh=COGdE4J7i/JowbiaIr+B1BVuYkO7paOys0ml3mgF0z1=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=FW3RXUpd/yxQhxn6AkLdX+wsrGO+nehlnL8ueN2mjwo0iq4tD6KqCSTZcIxlvd6MYbejJR/Qb/E3tvX4gPaGjFruT6XoVPlFRZuGWy8ELtdmwsAzJjFMKUqapF2m4Ez4IxKXwpjC99+KvQyTbjN0S1LVQgMamU7vNW2brYLuEZ4xWg7o18TLKp2fSLJBZhpZoyTNYu/qSlS0WHkVScqR8+Hp/DHU0v4KZk34FSyzgCjHAfN2r69FM52iSG+DcHtoAJnyF//uEI2KIy7Tz/V40F68BT5IZBBS9S86ss/SNFmb/slvKa8auLf5W0Fm+sOjnK+CXAputEOqa+aWFmK44A== X-YMail-OSG: UIDtG1wVM1meeEWNQFdZJfBTOX0zos2sg18kUvrthSkMp_dmMAiOZ3AbAKCVT7K beb_tR51tiiAVLN.5y5JT3qwrmMcgAvFJEnSw2grIHwT5t.RkwO4sZ7L3ygiIDdEHQW_Vr26o._v 9xW34l9NEIeNlpPBSLqKI4hti4S_jg9XbLVD.oEOwV5aEWPL5vAFIF5n0Lpeg2ib.mlGeoWP5Q1z YbHa0bBMCJC74e3h611UHOagTt4z3gpIfF10mJZbC.I6kk7jVsC6mUxqgPx4do4eM64eieMbYP6C ImEB.qkhuPDrbXdnlqFnt5qzveWxgawKt0KlWbKV_15lyOYFiHATUR5MoFvn1rTHBjubW2LWx1rE DtPDbuHAPGsfIK82S4B7eYV7WaoNN2WqzPm8mpNfkfXvCvLFFJSai7LMgV3_sAu9vwWjxWLM3LLn 7uOq9AROC7Rcxt0pc0EjXiM5gOM5iHLiPd9mkaQ.4wjg1UGiqzjMAAV8P4y2t1LIqVkuDuSVljN6 CMHKlftyJ3lmdKy8aQ625ZNPWe9jOGT2V8hIKP9vXQuOwSoaFVL_pyfyzJI_5jY8kVfKO0PufYct iO71mgZaH0bFEWSJhYpzmH5Pfv2JT7YfvXp9w_do82dpIQiLTU0_GFfxNtIzc7wqvAMqHXhviRNS aC7G3eOmID60LDtTjFQ66hytMQ0S_g8O1i9aPEpU_aivgdJWWv.rQMdQrlZhPHMrQcli1kCNNds4 mz7l2a_pr0uspFpZZQfqog05fZBtp9CxUWlcLzlBgpMt.1h4hwdaHglJWDTdosPe79HlI.4lUVJy quWFbR_b29aOKV8YNuIigvH0JiMl1vVYVpTvKyFYpt X-Sonic-MF: X-Sonic-ID: 53fe491e-66bc-4145-8c27-c5f3ae18ae87 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Jul 2023 00:19:43 +0000 Original-Received: by hermes--production-sg3-67fd64777-z82qw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a00c8dd67d69e590a1dd705d03ede441; Wed, 05 Jul 2023 00:19:36 +0000 (UTC) In-Reply-To: <87jzvfohtg.fsf@catern.com> (sbaugh@catern.com's message of "Tue, 04 Jul 2023 14:46:36 +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:264612 Archived-At: sbaugh@catern.com writes: > I think you might be misunderstanding me? Just to say again, in the > normal case, this would not add extra cost. This would only add extra > round trip cost in cases which, as you say below, currently just confuse > and break Emacs. It is extra cost, for an insignificant problem whose fix is unwarranted. > (Also, the entire point would be that this component would move from > being synchronous to being able to run in the background, concurrent > with other things.) No, setting up the selection transfer will still remain synchronous, and x-get-selection-internal will continue to block. > This is becoming tangential, but, yes, I will bite that bullet. "while" > should also check for and run timers and selection converters, when Lisp > code opts-in to that behavior. I can think of several ways to implement > this without hurting performance. That's unsafe, and that's simply not how Emacs works. You're talking about turning code utilizing while into signal handlers with strict reentrancy requirements. > IMO the major issue with the Emacs UI at the moment is that it blocks > too much, relative to "modern" applications. Some of this blocking can > only be fixed by speeding up Lisp execution, but substantial parts of > this blocking can only be fixed by making Emacs more concurrent - that > is, making it possible for Lisp code to run concurrently with other Lisp > code, on an opt-in basis, instead of blocking all Lisp execution while > operations like gui-get-selection and call-process are running. Other UI toolkits also block waiting for selection data to arrive. They even block when responding to selection requests, while Emacs can respond to multiple outstanding selection requests simultaneously. > Here is the real-world use case: When I yank I'm willing to wait for 2 > or 10 seconds for the paste to complete, since the paste is what I > actually want. But when I kill-new I want to wait less time, because > the save-interprogram-paste-before-kill behavior is just a nice-to-have, > which I want to happen if it's convenient and fast, not the actual thing > I want to do. Have you actually tried setting just `x-selection-timeout' and found it unsatisfactory? >> Let's not overengineer the system independent interprogram code with >> X-specific options. Thanks. > > A gui-selection-timeout would be fine with me, too. Maybe other systems > would benefit? pgtk? No other window systems will benefit from this arrangement, because their selection transfer mechanisms are not interruptable. `pgtk-selection-timeout' exists as lip service to the GDK selection mechanism and doesn't actually work on Wayland.