Re: User interaction from multiple threads

[martin rudalics]

>> I'd want to relax the organization of minibuffers.  Instead of
>> maintaining them in form of a stack, allow random access to the
>> minibuffer list.  Instead of having always only the one on top of the
>> stack active, allow to make any of them the active one.  And allow any
>> of them to appear in its own dedicated minibuffer window where the
>> selectedness of that window's frame indicates the currently active
>> minibuffer.
>
> That is a fine plan, but how does it make the issue at hand easier to
> solve?

Calling it a "fine plan" probably means that you doubt it can be
implemented.  Maybe you're right.

Anyway, the issues you raised when you started this thread were:

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

The last question you ask here would be resolved because the user types
"into a window" and that window is unambiguously owned by the thread
that should receive what the user types.

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

The non-main thread would prompt in another frame and the user can
choose whether to continue with her input or have a look at the
prompting frame and answer that prompt.

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

Each prompt has its own frame and the user can choose the order in
which to answer prompts by switching to the corresponding frame first.

martin