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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>