Re: A UI approach for making synchronous commands asynchronous

[Spencer Baugh <sbaugh@janestreet.com>]

Spencer Baugh <sbaugh@janestreet.com> writes:
> 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.

vc operations in particular would benefit this approach is vc
operations.  In particular, see bug#21969

That bug happened after vc-diff was made async: now diffs would pop up a
window which asynchronously would have the diff inserted into it.  But a
user complained that this was a worse user experience when the diff was
both empty and fast to generate: in that case, simply synchronously
running the diff and messaging "No diff" is nicer.

So the command was made async, but then reverted to sync because of UI
issues.

So as I said elsewhere, in bug#21969 the asynchronous implementation
*already* exists.  What was missing was a good user experience for the
asynchronous implementation.

I think my "backgrounding" approach would be a perfect solution to this:
start out blocking the UI waiting for the diff, but let the user hit a
key to "background" it, to immediately create the window which will
receive the diff asynchronously.  That works great both in fast and slow
diff-generation scenarios.