From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh 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 09:59:53 -0400 Message-ID: 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> <871qhnqkfg.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33584"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: sbaugh@catern.com, 64423@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 05 16:00: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 1qH33N-0008b9-D4 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Jul 2023 16:00:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qH337-0006ks-Lv; Wed, 05 Jul 2023 10:00:05 -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 1qH335-0006kX-Nl for bug-gnu-emacs@gnu.org; Wed, 05 Jul 2023 10:00: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 1qH335-0000Oh-FA for bug-gnu-emacs@gnu.org; Wed, 05 Jul 2023 10:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qH334-0007QO-RR for bug-gnu-emacs@gnu.org; Wed, 05 Jul 2023 10:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Jul 2023 14:00: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.168856560028502 (code B ref 64423); Wed, 05 Jul 2023 14:00:02 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 5 Jul 2023 14:00:00 +0000 Original-Received: from localhost ([127.0.0.1]:38747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qH332-0007Pe-DE for submit@debbugs.gnu.org; Wed, 05 Jul 2023 10:00:00 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qH330-0007PR-Mx for 64423@debbugs.gnu.org; Wed, 05 Jul 2023 09:59:59 -0400 In-Reply-To: <871qhnqkfg.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Jul 2023 08:19:31 +0800") 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:264634 Archived-At: Po Lu writes: > 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. The insignificant problem is Emacs potentially getting the wrong selection if we interrupt an incremental selection transfer? I'm confused, it seems like that contradicts what you said earlier. If interrupting an incremental selection transfer is an insignificant problem, then there should be no obstacle to automatically interrupting the incremental selection transfer if it's too large. >> (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. OK, so we are doing at least as good as other toolkits when it comes to retrieving the selection. But at my site the UX is still worse than other applications because save-interprogram-paste-before-kill makes taking ownership of the selection block, while for other applications it does not. And save-interprogram-paste-before-kill is a useful feature, and I want to make it work. >> 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? Yes. x-selection-timeout is configured to 5 seconds for every user at my site. They still find it unexpected and complain when killing takes that long.