Re: A UI approach for making synchronous commands asynchronous

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Thu, 27 Jul 2023 10:22:17 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > 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?

And you wanted _those_ to be asynchronous?  What would that buy us??
And when I asked a question about a specific command, you describe,
below, something very different...

So now I'm completely confused regarding what you have in mind.  In
particular, since both the prefix argument and the key sequence that
invokes the command are completely detached from the command itself,
and are basically processed by the Emacs main loop.

> I don't care about the terminology, so what would you call this category
> of questions?

I have no idea.  Moreover, I'm not even sure why we should find some
terminology, because the collection of things you call "UI" is not
meaningful for the issue at hand, which is how to make Emacs "less
blocking".

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

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?

More importantly, why do you think this kind of "backgrounding" will
be possible without deep changes to the Emacs main loop and to the
implementation of the commands as well?  You are basically describing
an Emacs that can run several Lisp threads concurrently, and we just
had (or are still having) a long discussion outlining the problems and
very non-trivial solutions for that.