Re: A UI approach for making synchronous commands asynchronous

[tomas]

On Thu, Jul 27, 2023 at 10:32:34PM +0300, Eli Zaretskii wrote:
> > From: Spencer Baugh <sbaugh@janestreet.com>
> > Date: Thu, 27 Jul 2023 14:22:04 -0400
> > 
> > Ideally the buffer would update incrementally with the new or removed
> > names as they happen, and be fully updated once the rename is finished.
> > 
> > That can be difficult to implement, though.  And also, for some kinds of
> > operations, it's not clear what the buffer should look like while the
> > command is half-done.
> > 
> > So here's another idea that would help with that: maybe we could have a
> > kind of buffer-specific blocking.  A "blocking" buffer would refuse all
> > input and commands while it's "blocking", and it wouldn't update, but
> > the user can switch to other buffers and edit them without a problem.
> > So, buffer-specific commands wouldn't work, but commands like C-x b and
> > C-x o would work.  It might be kind of like how term-mode works today.
> 
> 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).

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.

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"?

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.

Spencer: am I right?

thanks
-- 
tomás

signature.asc
Description: PGP signature