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:08:21 +0000 Message-ID: <8734z7260a.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30788"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , 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 12:07:29 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 1qjGan-0007mN-BA for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Sep 2023 12:07:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjGaV-0006Kw-RV; Thu, 21 Sep 2023 06:07:11 -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 1qjGaU-0006Km-Gi for emacs-devel@gnu.org; Thu, 21 Sep 2023 06:07:10 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjGaS-0003K2-9G for emacs-devel@gnu.org; Thu, 21 Sep 2023 06:07:10 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id C232D240029 for ; Thu, 21 Sep 2023 12:07:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695290825; bh=HI9Yot8EIh3sdF/u+PAJLl64/F3eNjU9cV2m/9yB5RM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=iMa7QO34aGKZU4+RnMBnfKyxkxFxrTw4RS4Uy53byEGjf0eYb4UMaguWXiOcTCZyL goIjDnNB6DRv9DPcNvEZdvbWR9Oke2NZreXBduujLO/EgVEbdNVwAngOchIoaAQhY8 L0mYOD42Ksw0yvFlYTKXfmivwPYqfcuEHTwTLDV8hglpG1PrB5fTK8YHOBvw60XiX+ bkYTH7nil+BqqB/fHtnjvWC3qApLy9K7sUlEpxhXkHokx+ISjes1ZFF4rz6cKj3aUn L3fy6ZmBCTVlcZZIq8y5UwWbZ7IZKjOV7iLB1bQdq6KQZ2otO3Mk8dBL+4kgWM6/ly /i2Rr/jNPfPhw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Rrrfd04L1z6tw8; Thu, 21 Sep 2023 12:07:04 +0200 (CEST) In-Reply-To: <83v8c5awj0.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.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:310882 Archived-At: 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at