Re: User interaction from multiple threads

[Eli Zaretskii]

> From: Gemini Lasswell <address@hidden>
> Cc: address@hidden
> Date: Sun, 19 Aug 2018 16:08:38 -0700
> 
> 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.

I have difficulty understanding how this "queue" model will work.
Suppose the main thread has some way of figuring out when to show the
first prompt on that "queue", then what? how (with what API) does it
show the prompt, and how does it read the response?  Remember: the
prompting thread called some function, like read-file-name, and that
function has its own ideas for how to interact with the user -- how
will the prompting thread tell the main thread all those details?
Some of the details reference variables that are local to the
prompting thread's current-buffer, about which the main thread knows
nothing.  The main thread will need to thoroughly "emulate" the
prompting thread to DTRT here.

Then there's the issue of passing the result to the prompting thread.
Unless you want to ask the programmer of that thread's function to
write specialized code for user interaction, the prompting thread
expects to get the keyboard input through the normal input machinery,
like read_key_sequence.  How will that be possible with the "queue"
model?

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

What about input functions like read-char, which read a character
without placing the cursor in the minibuffer?  How will we ensure your
principle above is honored?

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

This means some of the user input should go to the prompting thread,
while some other part ("C-x C-o" in your example) should go to the
main thread, so that it switches to another frame.  How will Emacs
know which part of user input is intended to what thread?

Thanks.