[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A UI approach for making synchronous commands asynchronous

From: Spencer Baugh
Subject: Re: A UI approach for making synchronous commands asynchronous
Date: Thu, 27 Jul 2023 14:22:04 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

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

Ideally the buffer would update incrementally with the new or removed
names as they happen, and be fully updated once the rename is finished.

That can be difficult to implement, though.  And also, for some kinds of
operations, it's not clear what the buffer should look like while the
command is half-done.

So here's another idea that would help with that: maybe we could have a
kind of buffer-specific blocking.  A "blocking" buffer would refuse all
input and commands while it's "blocking", and it wouldn't update, but
the user can switch to other buffers and edit them without a problem.
So, buffer-specific commands wouldn't work, but commands like C-x b and
C-x o would work.  It might be kind of like how term-mode works today.

So in that world, the user would execute a dired rename operation, and
then execute C-M-z to background it, and that would cause that dired
buffer to stop responding while the rename is proceeding, while other
buffers continue to work.

One question is what happens to the user's input when the buffer
"blocks".  Today when Emacs as a whole is blocking, key input gets
queued up and executed when Emacs resumes.  Should the same happen for
blocking buffers?  Or maybe any key input should just immediately result
in errors being printed?  The latter seems preferable, and it wouldn't
be a compatibility break because the user would have to run C-M-z to
trigger such behavior.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]