Re: A UI approach for making synchronous commands asynchronous

[Eli Zaretskii]

> Date: Fri, 28 Jul 2023 06:32:26 +0200
> Cc: Spencer Baugh <sbaugh@janestreet.com>, emacs-devel@gnu.org
> From: <tomas@tuxteam.de>
> 
> > Here you already describe the same "blocking" or "locking" that was
> > discussed at length in the other thread about concurrency.  Which I
> > think means that you are basically thinking about the same ideas with
> > the same issues and possible solutions.  It is not a different set of
> > ideas.
> 
> I think Spencer is onto something here. The really "fun" part in all
> this multiprocessing part is the interaction with the user (as an
> independent entity).

I'm not saying this doesn't deserve being discussed and considered.
I'm saying that without some kind of plan for _implementing_ the
features such a MO will need, discussing the UI aspects of this is not
just premature, it could be simply a waste of everyone's time.
Because if we conclude that making this happen in Emacs means
redesigning and reimplementing most of Emacs, then those UI aspects
are no longer relevant, since that "New Emacs", if someone will ever
undertake the job of coding it, will look and feel differently anyway.

> Spencer's idea is just one possibility. Another would be to just lock
> "part of a buffer" (whatever that means,see below): for example, in
> Org-Babel, where a snippet of the buffer is passed for evaluation to
> some external process and the results (think stdout) are inserted in
> a specific region of the buffer, you only have to keep a "lock" on
> this.

Currently, the "lock" is implicit, because Emacs simply waits for the
process to finish its work, and then inserts the output into the
buffer, before it proceeds to processing any further input events.

> Now, what happens if the user deletes a whole region containing that
> "part of the buffer"? How does Emacs signal to the user that this "part"
> is currently "moving"? Should that "part" be intangible? How does Emacs
> signal that it's "done"?

These questions are currently irrelevant, because the problems cannot
happen.

Figuring how to allow Emacs do something while another thread runs a
program which could affect buffers or other globally-visible data
structures, is the main difficulty, and was/is discussed at length in
the "concurrency" thread.

> I think Spencer's original mail was a proposal to think about such
> things and to try to discuss and develop "language elements" (not
> in the sense of "computer language", more of "user interaction
> language"), that's how I read his "user interface" term there.

I understand, but I don't believe we can develop such "language
elements" without having some idea about the implementation aspects
that would enable such behavior.  Without such an idea, discussing the
UI aspects has no basis on which to build it and on which to accept or
reject proposals.