From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 19:18:36 +0300 Message-ID: <835y6zlkf7.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6593"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 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 18:19:30 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 1qGikT-0001Vl-2f for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Jul 2023 18:19:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGik6-0003Uu-RU; Tue, 04 Jul 2023 12:19:06 -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 1qGik3-0003UN-7q for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 12:19: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 1qGik2-0005gg-12 for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 12:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGik1-000863-Tf for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2023 12:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Jul 2023 16:19: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.168848753031091 (code B ref 64423); Tue, 04 Jul 2023 16:19:01 +0000 Original-Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 16:18:50 +0000 Original-Received: from localhost ([127.0.0.1]:36481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGijp-00085O-ID for submit@debbugs.gnu.org; Tue, 04 Jul 2023 12:18:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGijo-00085A-2E for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 12:18:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGijh-0005bw-LW; Tue, 04 Jul 2023 12:18:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=preWAMfcFqlWNgyIbHlwbN1I3lAfVXu7lkqkx32fafc=; b=jNx4+AZgkBEc jFX3BTG3k+1MnbW5B9+0fLhE2d6ppluAbb195rBHI67vU1iqHKu8/orYpktfMLu/3SFfIDftiDlzX nY/Vz94D9cfzmvjatt8MhD/XXEArt3+0UCd6FYZ4Sc1Oe3ntMeoMyEMFFydWSqtA6EwMSdEQ7ypKX TwppLSTbGVuuyDEVqPyG0bDfUZXm+/ix0pEu88iRBL0LQh0dLsFtif981OQTNCtnJIfRoqeCY6Jbh oIeNBeBnmkV5ox8870C7zAiqPUdzRUFrzNK0j4o/Ngo8OzZsCMkYJZSMKiXDhzZN4vDCyjl7MNIU0 W+mw2kLlajh6ulQXSpj8kg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGijh-00020y-5L; Tue, 04 Jul 2023 12:18:41 -0400 In-Reply-To: <87jzvfohtg.fsf@catern.com> (sbaugh@catern.com) 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:264595 Archived-At: > 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. 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 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).