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.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Thu, 21 Sep 2023 13:12:57 +0300 Message-ID: <83ediral7a.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22867"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 21 12:13:37 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 1qjGgj-0005jV-Hp for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Sep 2023 12:13:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjGgC-0008FZ-FE; Thu, 21 Sep 2023 06:13:04 -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 1qjGg5-0008Cb-WF for emacs-devel@gnu.org; Thu, 21 Sep 2023 06:12:58 -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 1qjGg1-0004Y1-1R; Thu, 21 Sep 2023 06:12:56 -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=kbRtxb7xhucgkE5oNE+ILC8ciLtzBZshsG+OxsWAN/Y=; b=M5VWh58d3KWP lXizgiMt/IM1ax0H/EWyLK+qXz3iHODYW2/Den9NTtarDHhyzgQ6xr/VbnwtxWDgAGgCPsqpLOCet WU0O33VXeUTqwiStFbfhFAvt1MARoGIdlXO+aAMsrnEeW5efV4QNt2qKypjM6LjeM2x3YbXXgFFmV eLJOowhdvBgD1zfkibpwHI4KiIJZWfkKDc1sGGdne77W9EheS4KL9B4Egru102S5MqTuM1QovfD0l xsl7nIJCyJ8UuTW4nY3mr6EZcPnmZsm86x8FFWXwL480W0ZI5Oy1wg45j1rsUOQqe9HcuinUZwRw6 mTVK82/QRkGhbeHzXqQqGg==; In-Reply-To: <8734z7260a.fsf@localhost> (message from Ihor Radchenko on Thu, 21 Sep 2023 10:08:21 +0000) 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:310884 Archived-At: > From: Ihor Radchenko > Cc: Po Lu , acm@muc.de, incal@dataswamp.org, > emacs-devel@gnu.org > Date: Thu, 21 Sep 2023 10:08:21 +0000 > > Eli Zaretskii writes: > > >> We will have a window whose point does not reflect its contents on the > >> display. A supervening redisplay within the main thread will give due > >> consideration to its new value when it does transpire. > > > > I don't understand why only the main thread is allowed to do that. > > What is special in the main thread wrt redisplay that other threads > > are forbidden from doing that? Would it be okay to have a separate > > non-main redisplay thread, for example? if not, why not? > > Apart from toolkit considerations, consider two asynchronous threads > requesting to display something in the echo area. We cannot allow one > thread "cancel" displaying its message by another thread - this will > lose one of the messages that should be displayed to user. So, there at > least should be some kind of queue for threads trying to display > something in the same window. > > Another scenario is one thread displaying multiline message while > another thread displaying a window adjacent to echo area. Let's say that > the thread redisplaying window started running first, considered its > window geometry, and started calculating the glyph matrix according to > the known number of lines fitting that window height. Then, "message" > thread wants to resize echo area to fit its multiline message. What > should the "window" thread do? Should it cancel its redisplay? Restart > it? Wait for the "message" thread to finish? It is not very clear and > likely depend on the specific scenario at hand. 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 any case, having to deal with multiple simultaneous messages is a far cry from disallowing any non-main thread to display anything.