Re: A UI approach for making synchronous commands asynchronous

[Eli Zaretskii]

> 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.

> So in that world, the user would execute a dired rename operation, and
> then execute C-M-z to background it, and that would cause that dired
> buffer to stop responding while the rename is proceeding, while other
> buffers continue to work.
> 
> One question is what happens to the user's input when the buffer
> "blocks".  Today when Emacs as a whole is blocking, key input gets
> queued up and executed when Emacs resumes.  Should the same happen for
> blocking buffers?  Or maybe any key input should just immediately result
> in errors being printed?  The latter seems preferable, and it wouldn't
> be a compatibility break because the user would have to run C-M-z to
> trigger such behavior.

Queuing input means blocking UI, so if we lock various parts of Emacs
while a command runs, we will have achieved nothing.