Re: User interaction from multiple threads

[Eli Zaretskii]

> From: Richard Stallman <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden,
>       address@hidden,
>       address@hidden
> Date: Sat, 25 Aug 2018 15:11:10 -0400
> 
>   > My conclusion from the discussion is that when a thread asks for
>   > input, it might be too late, because the prompt was already issued.
> 
> In Emacs, prompts are usually output by a function
> whose main purpose is to ask for input.  Is this no longer true?
> So in practice it is easy to tell what is a prompt that asks for input.

I think we are miscommunicating regarding what exactly constitutes
"asking for input".  I assumed you meant low-level functions such as
wait_reading_process_output, but you seem to be talking about much
higher-level functions, like read-from-minibuffer.

>   > > until the thread exits?
> 
>   > Not until it exits, until it no longer needs to interact with the
>   > user, for the current transaction (whatever that means).
> 
> How does a thread say that it no longer needs to interact...?

We'd need to provide a new API for that.

>   > I'm saying that fixing the prompt itself is a better alternative,
>   > because we will always give the prompt more screen estate than to the
>   > thread ID.
> 
> Emacs could add the thread ID at the start of a prompt
> when there are multiple threads that could be asking for input,
> such that there is a possibility of confusion.
> 
> That could avoid lengthening the prompts in the usual cases.

I don't see how this would solve the problem, since thread IDs will
always be quite short.