Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 17 Aug 2018 09:24:31 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: michael.albinus@gmx.de, emacs-devel@gnu.org
> 
>  >> 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.

No, I actually meant "fine" literally.  I didn't think about it enough
to reach any conclusions, but I certainly don't see up front why
wouldn't it be doable.

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

You might be thinking about some mechanism we don't have, and didn't
discuss yet, because currently windows and buffers are not "owned" by
threads.  Any thread can modify any buffer and call any functions that
manipulate windows.

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

That just postpones the question, because now we need to have some
infrastructure in place that "knows" which frame's input goes to what
thread.  And it leaves intact the fundamental implementation-level
difficulty, about which I will write shortly: namely, that we have
only one input "pipeline", which needs to somehow be enhanced to
multiplex between several threads.  The fact that the prompt is shown
in another frame doesn't resolve the difficulty with channeling the
input in response to that prompt, especially when multiple different
prompts are being displayed at the same time.

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

See above.

Thanks.