Re: A UI approach for making synchronous commands asynchronous

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Wed, 26 Jul 2023 15:07:39 -0400
> 
> 
> Basic well known facts:
> - Sometimes Emacs blocks for a long time while performing a command
> - This is annoying because I don't want to sit and wait
> - Making it so I don't have to sit and wait requires two things:
>   Step 1. Changing the implementation of the command
>      (to be capable of running while Emacs handles user input)
>   Step 2. Changing the user interface of the command
>      (e.g. to display a buffer or message when the command is done)
> 
> Step 1 is difficult on its own and is specific to individual commands.
> I'm not going to talk about step 1 at all.  (We've talked about it a lot
> recently in the "Concurrency via isolated process/thread" thread)
> 
> Instead, I have an idea for step 2!
> 
> Even once step 1 is already done, step 2 is still a bunch of work: we
> have to design a non-blocking UI for the command.

You have lost me right here.  In Emacs, commands don't have a UI: the
job of displaying the buffer modified by a command is not a job
commands must do.  Instead, the display engine kicks in and does that.

This feature is one of the basic design features of Emacs.  So to talk
about this, we must be on the same page regarding how this stuff works
in Emacs.

In addition, it is not clear what hides behind the "UI" notion that
you have in mind.  There are two aspects to UI: input and display.
Which one are you talking about?  Only the display or also about input
(via the keyboard, mouse, window-system events etc.)?

> The new feature is that if they get annoyed with how long a command is
> taking, they can hit C-M-z to make the command "go into the background":
> convert to some kind of non-blocking UI, like displaying a buffer with
> progress or messaging when the task is done, as appropriate for the
> individual command.
> 
> We could also have a prefix (perhaps C-M-&) to run a command in the
> "background" - that is, in a non-blocking way - from the beginning.

How is this different from your Step 1, which is to change the command
to run asynchronously (a.k.a. "in the background")?  The main problem
in what you describe is not delaying the redisplay (although it is
also not trivial), it is the fact that while the command runs,
something else, like user input, can change the buffer or some other
aspect of the global state behind the command's back.  Dealing with
this is not a UI problem, it's a problem for the command.

> In particular, I was thinking about this for file operations in dired.
> Many dired file operations can take a long time, during which they block
> Emacs.  Actually changing their implementation to run during user input
> handling (step 1) is a separate matter (and I have separate ideas about
> how to do that), but I think the UI aspect (step 2) would be well served
> by this "backgrounding" approach.

Please describe in more details how this would work for some file
operation in Dired.  Suppose I mark some files and then run some
command which searches them or renames them or deletes them -- how
would this work under your hypothetical "backgrounding"?