Re: User interaction from multiple threads

[martin rudalics]

>    . 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 we make a rule that each thread owns a frame with a minibuffer, the
decision which thread receives input on a GUI is left to the windowing
subsystem.  We would have to emulate that behavior on a TTY somehow
but that should be an implentational detail.

>    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?

The partial key sequence should be preserved and typing resumed where
it was interrupted when the user switches back to the main thread by
selecting a frame owned by the main frame.

> If
>    the latter, how do we indicate to the user that there is a prompt
>    from another thread?
>
> 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?

If each prompt has its own frame, this is trivial.  The user will
answer the prompt of the frame that happens to be selected and will be
able to switch between prompts by selecting their respective frames.

Obviously, for each frame/thread we would have to record its input
state to be able to resume an interaction where the user left off.

martin