Re: A UI approach for making synchronous commands asynchronous

[Spencer Baugh <sbaugh@janestreet.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>> 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.)?

By "UI" I'm referring to the category of things which includes questions
like:
- should I call display-buffer or message here?
- what keybindings should I use for this set of commands?
- should I provide a prefix argument for so-and-so behavior, or
  put it in a different command, or make it customizable?

As distinguished from the implementation.  The implementation might be
complex, but we might hide that complexity from the user.  (as I believe
you have said before to me)

This is a meaningful category because it is all things we decide on
primarily based on what's best for users, and many different choices are
possible and easy to program.  Whereas the implementation is determined
by the details of the problem and the platforms we run on, and the
possibilities can be heavily limited.

I don't care about the terminology, so what would you call this category
of questions?  I'll use that term from now on.

I did not mean anything to do with the display engine, which I would
class as "implementation", since it's a fundamental hard problem where
we need to make compromises and hard choices, although of course it's a
bit fuzzy.

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

Yes.  I agree that is a problem for the command, and something which the
command needs to solve.  I call that the "implementation" of the
command.  The "UI" of the command is different.  Perhaps my explanation
of what I meant by "UI" clarifies this.

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

1. I dired-do-rename to move directory "foo" from /home/sbaugh to
/mnt/sbaugh

2. Emacs messages:
  Renaming ~/foo to /mnt/sbaugh/foo...
And stops responding.

3. After about a second I realize that this is a cross-device move which
will take several minutes (a common occurence for me).
I decide I don't want to wait, so I hit C-M-& and Emacs messages:
  Renaming ~/foo to /mnt/sbaugh/foo... backgrounded.
I switch to some other buffers and do some work.

4. Several minutes later, Emacs messages:
  Renaming ~/foo to /mnt/sbaugh/foo... done.



Alternatively, if it was a fast operation:

1. I dired-do-rename to move file "bar.txt" from /home/sbaugh to
/home/sbaugh/projects

2. Emacs messages:
  Renaming ~/bar.txt to ~/projects/bar.txt...
and stops responding.

3. The operation completes after 100ms, before I have time to get
impatient, and Emacs messages:
  Renaming ~/bar.txt to ~/projects/bar.txt... done.