A UI approach for making synchronous commands asynchronous

[Spencer Baugh <sbaugh@janestreet.com>]

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?