Re: User interaction from multiple threads

[martin rudalics <rudalics@gmx.at>]

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

Agreed when I think of extravaganzas like 'yes-or-no-p' calling
'read-from-minibuffer' and prompting in the minibuffer and 'y-or-n-p'
calling 'read-key-sequence' and prompting in the echo area and using
'cursor-in-echo-area' to make one virtually look like the other.  But
in this thread you wanted to "first pay attention to conceptual issues
related to this, before we start talking about implementation" and
that's what I've tried to do.

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

Isn't serialization the hard trick we're pulling ever since?  How to
maintain the order and duration of objects appearing in the
mini-window, how to avoid that tooltip or eldoc text shadows whatever
goes in there?

martin