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 16:48:06 +0000 (UTC) Message-ID: <87h6qjoc6y.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> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> 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="8464"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 04 18:49:24 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 1qGjDP-0001wN-On for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Jul 2023 18:49:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGjDE-0005K2-Ga; Tue, 04 Jul 2023 12:49:12 -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 1qGjD4-0005G2-5R for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 12:49: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 1qGjD3-0004Lk-Nb for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 12:49:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGjD3-0000lm-K8 for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 12:49: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 16:49: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.16884892942756 (code B ref 64423); Tue, 04 Jul 2023 16:49:01 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 16:48:14 +0000 Original-Received: from localhost ([127.0.0.1]:36531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjCI-0000iL-7E for submit@debbugs.gnu.org; Tue, 04 Jul 2023 12:48:14 -0400 Original-Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:50474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjCG-0000hQ-6c for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 12:48:13 -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=aCpyf+/8/ip3XpmkPEBnKDfvnZSFs3V8jgMlG8aKDzs=; b=INpLm+uE8NVzkkjeI9LIYSXMFORqFEMAwmow4Vm9XKHt3/j+emnXuNXr4xi+s8DQ1hp1 J+pqAFrnNmbzZf0HW0AE1+M9dCmqq/16NcZJy6+9GIlxHuQczkIxZiSRkeon7/8yXJBf/3 QOZMEPqfdU4LiV47KjouQdxRUJCf59cF5Fubay1dJ4u2bAX+jLaIkzIiNs+s6UHrCdJofZ +YeJxUmcG0eIde4p+G9hJnFIpIDl1Cs2htro/yxjV+SP4MQch/3FdskLyF+nEkK52IEBpD hT5VEk3gWHKnBQyTx3JCO1+tCtEGkzizbCJoQUiJv0tJ+ByUoo9JmVdzcJLcsujA== Original-Received: by filterdrecv-d7bbbc8bf-jcg2g with SMTP id filterdrecv-d7bbbc8bf-jcg2g-1-64A44D46-B 2023-07-04 16:48:06.080754702 +0000 UTC m=+4727307.931957906 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-5 (SG) with ESMTP id yUH3CEkjSEKmh1k-xj68Xw Tue, 04 Jul 2023 16:48:05.939 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Original-Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id 8E3EC6009A; Tue, 4 Jul 2023 12:48:05 -0400 (EDT) In-Reply-To: <835y6zlkf7.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 04 Jul 2023 19:18:36 +0300") X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbIfc5qXNE3Om/d+wnoBbCsMiJaRuY38EScS79gK0mkhiMOx+kwqq1qMvwPAq718LqS6+WY4B/Od2XfifL1MkfOobzrFlfWbLOI+5OHMzMvbSCVNe0RO3lJkaw0lDdFF3xK16Be1htDlDx6oQdRNrYNTZDchUx/G3KghXNszQ28Ktg== 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:264598 Archived-At: Eli Zaretskii writes: >> Cc: Spencer Baugh , 64423@debbugs.gnu.org >> From: sbaugh@catern.com >> Date: Tue, 04 Jul 2023 14:46:36 +0000 (UTC) >> >> IMO the major issue with the Emacs UI at the moment is that it blocks >> too much, relative to "modern" applications. > > That is true, but it cannot be fixed by small half-measures. The > basic Emacs design _assumes_ this single-threaded operation, and many > of the low-level parts will simply break if the assumption becomes > false. Some will break visibly and loudly, some will break subtly and > silently, but they _will_ break. We have seen this many times: the > seemingly-confusing code which does things no one completely > understands turns out to do all that for good reasons, which only > become visible when we in our arrogance boldly make changes no one > imagined when this was designed and implemented. And people who > designed and implemented it, and improved it over the years, were and > are very clever, and knew what they were doing and why. > > The _only_ sane way of getting a non-blocking Emacs is to redesign all > of Emacs around that idea. > >> 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. > > You cannot "make Emacs more concurrent", not by and large. We can > make small improvements here and there, if we tread cautiously and do > careful damage control after each such change, but that's all. That's all I ask for, the ability to make such small, careful, cautious improvements. I think with enough of these, we will get to a much better place. As long as every individual small improvement is not rejected just because it is too small of an improvement... And I have the ability to test these improvements at my site (of ~500 users with diverse configurations), so I am in a decent position to make these small improvements without breaking Emacs. As long as I don't have to carry those patches forever... > If you look at the low-level code in Emacs and take time to understand > how it works, you will agree with me. (And if you don't agree, we > will have this very argument again many times in the future.) We > should accept that fact, and either live with it or start a > new-generation Emacs, based on very different designs. Anything else > is just lying to ourselves. I've stared at low-level code in Emacs a good amount, but certainly I wouldn't claim to understand Emacs yet. Nevertheless... I think Lisp threads shows that this is not true. With that as the foundation, and making incremental small improvements to the C core to increase the amount of stuff that can be done in Lisp threads, we can build a new-generation Emacs incrementally within the old. IMO the reason we haven't done this yet because Lisp threads are still very limited in what they can do without blocking. But we don't have to agree - I'm happy to make small, step-by-step improvements, which are justifiable on their own. That's what I'm doing now: I am trying to fix blocking issues which I get lots of user complaints about, not change things for no reason. >> 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. > > Ha! Lexical-binding transition is nothing near what you propose. It > changed the language and its interpreter, but not the editor and its > infrastructure and primitives. What you suggest is several orders of > magnitude harder (read: impossible).