Re: User interaction from multiple threads

[Gemini Lasswell <gazally@runbox.com>]

Hello,

With the benefit of having read everyone else's suggestions to date,
here are my answers to your use cases:

Eli Zaretskii <eliz@gnu.org> writes:

> Use case #1:
>
>   . The main thread is waiting for user input.  The user didn't yet
>     type anything
>   . A non-main thread runs Lisp that prompts the user for some input
>
>  In this case, we probably want the following input to go to the
>  prompting thread, right?  But it might also be the case that the
>  user actually wants the input to go to the main thread, e.g. to
>  perform some unrelated command.  Should we allow that?  If yes, how
>  should Emacs know which thread should receive what the user types?

If a user sees the cursor in a text buffer and types a character and
RET, that should never be interpreted as the response to a prompt that
appeared just as she started typing and which she didn't notice in time
to stop.  This means that a prompt from a non-main thread should become
visible but not active, and the user should have to switch to the window
containing it to respond.

The user should, as now, be able to type C-x C-o or C-x 5 o during
read-from-minibuffer, and perform unrelated commands on another buffer.
The user shouldn't have to have a mental model of what threads are in
order to work with Emacs, and the simpler we can keep the Lisp
programmer's mental model of threads, the better off we will be.  So
those unrelated commands should be run in the main thread.

Perhaps the way to accomplish this is to always read keyboard input in
the main thread.  So when read-from-minibuffer, for example, is called
from a non-main thread, it would put the prompt on a queue for the main
thread to process, and then block until the response is ready.

> Use case #2:
>
>   Same as the previous, but now the user is in the middle of typing a
>   key sequence, when the non-main thread prompts.  For example,
>   suppose the user has typed "C-x".>

>   What do we want to happen now?  Do we "preempt" the main thread and
>   let the following input to go to the prompting thread?  Or do we let
>   the prompting thread wait until the main thread reads a full key
>   sequence and runs the command bound to it?  If the former, what to
>   do with the partial key sequence ("C-x") that the user typed?  If
>   the latter, how do we indicate to the user that there is a prompt
>   from another thread?

I don't think we should ever interrupt a key sequence.  The prompting
thread will have to wait.  To indicate to the user that there is a
waiting prompt, use a numeric indicator at the beginning of the echo
area or upper left corner of the minibuffer, like the recursive
minibuffer indicator.  In a graphical environment a white number on a
red ellipse would be a familiar clue to many users that there are
messages waiting.

> Use case #3:
>
>   Similar, but now 2 or more non-main threads prompt the user, one
>   after the other, in quick succession.  What should happen now, and
>   how will the user know there are multiple prompts?

The first thread should get to show its prompt and wait for a response,
and then show followup prompts if it can present them immediately after
the first is answered.  Other threads will block until the threads ahead
of them are done prompting.  The same numeric indicator as above could
indicate to the user how many other prompts are waiting.  A new
keybinding could allow navigation forward and backward through the
waiting prompts.  (This is inspired by Martin's minibuffer list
suggestion in
http://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00516.html)
Another new keybinding might send keyboard-quit to all waiting prompts,
which I would like to have available in the event that I do something
that unexpectedly creates 250 of them.