Re: Emacs design and architecture. How about copy-on-write?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Po Lu <luangruo@yahoo.com>, acm@muc.de, incal@dataswamp.org,
>  emacs-devel@gnu.org
> Date: Thu, 21 Sep 2023 10:08:21 +0000
> 
> Eli Zaretskii <eliz@gnu.org> 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.