Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 15 Aug 2018 10:06:40 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  >    . 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.

As you well know, when the user switches to another frame, we
redisplay the mini-window on the newly selected frame to display the
same prompt/echo there as was displayed on the previous selected
frame.  So what you suggest won't work without very serious surgery to
our handling of the mini-window (which is already quite complex and
fragile).

> We would have to emulate that behavior on a TTY somehow
> but that should be an implentational detail.

And that is another complication, of course.

I think that at least at first we should go for some kind of
serialization of using the mini-window, because having several ones
active at the same time is a much harder trick to pull.

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

Would be nice, I agree, but again probably not quite simple.