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 14:46:36 +0000 (UTC) Message-ID: <87jzvfohtg.fsf@catern.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> 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="35785"; 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 16:47:26 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 1qGhJN-00090i-PO for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Jul 2023 16:47:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGhJ7-00022P-EV; Tue, 04 Jul 2023 10:47:09 -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 1qGhJ0-0001zg-H4 for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 10: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 1qGhJ0-00028v-8C for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 10:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGhIz-0000Kg-Mp for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 10: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 14: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.16884820091251 (code B ref 64423); Tue, 04 Jul 2023 14:47:01 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 14:46:49 +0000 Original-Received: from localhost ([127.0.0.1]:36419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGhIm-0000K7-II for submit@debbugs.gnu.org; Tue, 04 Jul 2023 10:46:49 -0400 Original-Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:26334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGhIh-0000Jl-1a for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 10:46:46 -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=+pTNEUhtPJs2Bs//ZDT6rhq2vC+wy4qECb35mucE4mQ=; b=ITp2L1Hv90byoZ8rOJmkshf7soWWdtXJRuE685gXqqaZKlylq+I6D7XSm4f9vq2E8GjX p8CezI2dKsTggTs4L5uw3ZQA5Vbwt9YLnjH+ReFzn1ctP4wCaj1BNc4xlWalyZbXkAojrg 0z0Xm//vCKqqtWHJgnb2uQ9iohgKTWYCxXAI3FwkDYKIH9s3DtvOmw03v9gJv/ACocQudh nQyiWhlnEOzQAMWOkMNOcYi7c8jaWOQpG2adOsrw7rAY/Ve/H71PPYksA/Ee2+XjgAHiR8 q3Ac9cqwAteMTJ1txIc6fGjujCx3t2gOv+IDQBOkCkpOW1+OraOuvRHJyKMoZmvw== Original-Received: by filterdrecv-8684c58db7-nfltn with SMTP id filterdrecv-8684c58db7-nfltn-1-64A430CC-75 2023-07-04 14:46:36.697274847 +0000 UTC m=+4720084.975447428 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-16 (SG) with ESMTP id wf-GU24XSNqoUkjEvS-mOw Tue, 04 Jul 2023 14:46:36.364 +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 D16B36015C; Tue, 4 Jul 2023 10:46:35 -0400 (EDT) In-Reply-To: <87h6qjreyw.fsf@yahoo.com> (Po Lu's message of "Tue, 04 Jul 2023 21:19:51 +0800") X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbL8pxP/fGIayP8u9YrrwhcwZzKrjD/zsv42A4tqPhMX23ZjJskVzj7SSmxJLAzl5ojgs6MavhuhT2ix9huRmoNiyQ9insQilgCmbtV0xUPb+mwqBb+djDp8VAjjSqDwFBProiDO1oivvkG5esXkhtjb9F6xKdrslfx6zSNNIm6hkQ== 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:264588 Archived-At: Po Lu writes: >> 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. 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. (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.) >> 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. OK, interesting. So it's basically broken already today to interrupt a gui-get-selection... great. >> (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. 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. 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. I am aware this is a major undertaking, but I think it's important for Emacs to compare favorably with "modern" applications which don't exhibit as much random UI blocking. I regard this as basically equivalent to the lexical-binding transition. >> 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? 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. > 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?