Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> Cc: hw <hw@adminart.net>, gazally@runbox.com, rms@gnu.org, emacs-devel@gnu.org
> From: Phil Sainty <psainty@orcon.net.nz>
> Date: Wed, 29 Aug 2018 01:05:35 +1200
> 
> On 28/08/18 17:38, Eli Zaretskii wrote:
> > several minibuffers doesn't solve the basic problem, which is: how
> > should Emacs decide which of the threads' prompts gets submitted to
> > the user at any given time.  When we solve that basic problem, we
> > could talk about the details like whether this happens in the same
> > minibuffer or in several.
> 
> Backing up a little, the notion of multiple minibuffers seems like it
> could be relevant to the question of whether we are dealing with
> low-level user interactions, or with the higher-level functions used
> for asking the user questions.
> 
> Is that still an open question?

It certainly is, because when Emacs is idle at top level, and waiting
for the user to type the next command, the minibuffer is implicitly
taken, but without any function like read-from-minibuffer being
called.  So we still need some way of telling the main thread to stop
waiting and yield the minibuffer.

> IIUC the main concern about dealing with user interaction at a low-level
> was the point about the prompt already having been generated by the time
> the interaction takes place.

That was one concern.  The other is what I described above.

> At face value, it seems to me that if we had per-thread minibuffers
> then perhaps that concern goes away?

Not entirely, because there's still a problem of how and when to
display the relevant minibuffer in the echo area.  And the issue with
directing the input the user types to the right thread also stays.