From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Thu, 21 Sep 2023 10:35:14 +0000 Message-ID: <87sf77zue5.fsf@localhost> References: <83edizjn0v.fsf@gnu.org> <0518f65b-1dd1-6923-8497-da4d3aeac631@gutov.dev> <87sf7fc7kd.fsf@dataswamp.org> <834jjuk68t.fsf@gnu.org> <87cyyhc7uu.fsf@dataswamp.org> <83ttrsg9nx.fsf@gnu.org> <83h6nrg4eg.fsf@gnu.org> <83v8c7elan.fsf@gnu.org> <87h6nrwqvq.fsf@yahoo.com> <83msxjed5c.fsf@gnu.org> <83ediuck9t.fsf@gnu.org> <87cyydverf.fsf@yahoo.com> <83v8c5awj0.fsf@gnu.org> <8734z7260a.fsf@localhost> <83ediral7a.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3179"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 21 15:05:05 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qjJMf-0000Zw-FP for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Sep 2023 15:05:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjJL8-0007NL-70; Thu, 21 Sep 2023 09:03:30 -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 1qjJJ3-0002Ou-NY for emacs-devel@gnu.org; Thu, 21 Sep 2023 09:01:26 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjJJ1-0003Ba-8p for emacs-devel@gnu.org; Thu, 21 Sep 2023 09:01:21 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8DA77240103 for ; Thu, 21 Sep 2023 12:33:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695292438; bh=pMxUYAiDeLC88GHqvdj7A561dBGhM2fdWJ5HQhiecV8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ZxH4yFEp8CuxUVYYo6RJQd6IfUcVNWEkIrZL6Ke8H0u7x+q5WLESP7gN0L7kKhPB1 Lv5/nl+U3Asnyfo4hXVlffxRQbZ/ipkuxGe6Kg0qTvq//P0bcf2kH5hGUf0YkiVo8e Jcdsqq8SBWOsh/fLfN0+OAg68mC7M83sKJdCbY9zQySToyIc4fAR7LmTjXaKj5XA9h NMyGNCgnuh3TXxtwmKjnp6L2udbTA3tstF3GXrI/9hRGdgP37nVLTOOAtMxxU6+Uto 5JLUmiYq3/k88bA6bLC55dAB5q2OJE1xMbixZ6gzDbNKEqXELl4mt7BJ2qko5iyl3Z 5DKctRBkxmluQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RrsFd6125z9rxj; Thu, 21 Sep 2023 12:33:57 +0200 (CEST) In-Reply-To: <83ediral7a.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310893 Archived-At: Eli Zaretskii writes: > We have these situations already: arrange for some timer to display an > echo-area message after several seconds, then type M-x or something > else to enter the minibuffer, and watch how the message is displayed. > We solved this, more-or-less, in Emacs 29. In other words, it is some kind of primitive async queue, right? > In any case, having to deal with multiple simultaneous messages is a > far cry from disallowing any non-main thread to display anything. I agree. I also think that non-main threads should not be disallowed to trigger redisplay. However, (1) this redisplay should better be synchronous (first waiting for all other threads to finish their redisplay) when using the existing redisplay primitives. (2) we may want to introduce asynchronous API to not block during redisplay, when threads do not care about display-related call returning a value. For example, there is no reason to wait until a message if displayed for async thread reporting its progress. It might be better to have something like `async-message' that will submit a request to display when Emacs decides to. Of course, such async API should not rely on thread-local context. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at