all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* A UI approach for making synchronous commands asynchronous
@ 2023-07-26 19:07 Spencer Baugh
  2023-07-27  5:58 ` Eli Zaretskii
  2023-08-01 14:09 ` Spencer Baugh
  0 siblings, 2 replies; 13+ messages in thread
From: Spencer Baugh @ 2023-07-26 19:07 UTC (permalink / raw)
  To: emacs-devel


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.  For a lot of
commands, this is difficult.  Changing the UI to be non-blocking is a
big compatibility break, and can confuse and annoy users, and can be
just plain worse in the common case of a short-running command.

We could make blocking vs non-blocking configurable for each command,
but that adds more annoying configuration overhead.

Instead, perhaps we could add a new basic Emacs feature,
"backgrounding", inspired by job control (C-z) in Unix shells.

Commands supporting this feature could start out with a blocking UI.
When such a command is run, Emacs just blocks and doesn't respond to
user input.  The user can wait for as long as they like, and can
interrupt it with C-g.  This is how things are today.

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.

This UI approach:
- Doesn't break UI compatibility
- Doesn't require any configuration
- Lets users decide on what they want on a case-by-case basis
- Is already familiar to anyone who uses job control in Unix shells

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.  I think this approach would also work
well for some other commands.

Thoughts?




^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2023-08-01 17:11 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-26 19:07 A UI approach for making synchronous commands asynchronous Spencer Baugh
2023-07-27  5:58 ` Eli Zaretskii
2023-07-27 14:22   ` Spencer Baugh
2023-07-27 15:09     ` Eli Zaretskii
2023-07-27 15:32       ` Spencer Baugh
2023-07-27 17:31         ` Eli Zaretskii
2023-07-27 18:22           ` Spencer Baugh
2023-07-27 19:32             ` Eli Zaretskii
2023-07-28  4:32               ` tomas
2023-07-28  6:21                 ` Eli Zaretskii
2023-08-01 14:09 ` Spencer Baugh
2023-08-01 16:53   ` Helmut Eller
2023-08-01 17:11     ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.