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

No, I don't want those to be asynchronous.  I'm explaining what "UI"
means, since you asked.

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

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.

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.

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

Again, I'm talking here about what would be a nice *experience for the
user*.  Perhaps "user experience" is a better word to use here.

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.