Re: A UI approach for making synchronous commands asynchronous

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Thu, 27 Jul 2023 11:32:33 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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?
> >
> > And you wanted _those_ to be asynchronous?  What would that buy us??
> 
> No, I don't want those to be asynchronous.  I'm explaining what "UI"
> means, since you asked.

There must be some kind of misunderstanding.  In your OP, you said:

    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!

My interpretation of that is that you are suggesting to change the
stuff you call "UI of the command" such that the user will not need to
wait until the command finishes.  Is that understanding correct?

You then say that this "UI" consists of:

  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?

My interpretation of this was that you want to be able to use this
stuff while one or more commands still run.  Is that correct?

If both of the above are correct, then you are, indeed, looking for
making these aspects asynchronous.

> > What happens if during the time the command runs "in the background",
> > you go in the Dired display to one of the files that have been renamed
> > and press RET?  Or some command you invoke while the "backgrounded"
> > one runs wants to access or visit one of the renamed files?
> 
> Good question.  I'd say, let's follow what the shell does.  If you run
> "mv ~/foo /mnt/sbaugh/foo &" and then run ls, you'll see some of the
> files still in the source, some of the files in the destination.  If you
> try to access the former, you might get failures.

Emacs does not work like a shell.  For example, when a Dired command
runs, it often changes the contents of the Dired buffer as it
proceeds: e.g., renaming files modifies the Dired buffer to replace
their old names with new ones.  When other commands or you as the user
want to access that buffer, what do you want to happen, and what do
you want to see on display?

A shell doesn't have these problems, it just writes stuff to the
display and forgets about it.

> The user already can go do other things that interact with those files,
> while Emacs is moving them, which won't behave perfectly.  So I don't
> think we should take special care around them.

I actually think this is a tip of a giant iceberg, even in this very
simple example.  Ignoring these aspects is not recommended, if we ever
want something practical to come out of this.

> I don't care about what the implementation is.  I have thoughts about
> how we could implement this, but I am not going to discuss it in this
> thread, as I said in my initial email, since we already have a very long
> thread about that.
> 
> I just want to discuss what a good user experience would be, without
> talking about implementation.  This is necessarily somewhat speculative,
> since we could describe designs which are hard to implement.  That's
> nevertheless what I want to do in this thread, since I think it's
> useful.

Talking about UX without also discussing the implementation of that in
Emacs is not useful.  We all know how it looks and feels to interact
with a program where the UI, both input and output, are detached from
the processing engine and can work in parallel with it.  So I see no
reason to discuss how this should look, because we already know that,
and hardly disagree.  What exactly do you expect to achieve by
describing how C-z works in a Posix shell? are there any people around
here who don't already know that?

The problem is how to implement something like that in Emacs.  IOW,
the important part, and the only one worth discussing if we want
practical results, is how to implement such features without rewriting
all of Emacs.