bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks

[martin rudalics]

> It looks interesting, but please use something other than 'loose' to
> describe the behaviour. I guess 'dedicated' is already
> overloaded. 'separate', 'no-echo'....?

The behavior is more complicated than that.  In escalating order a
user can:

(1) Put minibuffer and echo in a shared "fixed" window at the top of
the frame.  Together with the standard behavior, this is considered a
fixed minibuffer window because it never goes away.

(2) Put minibuffer and echo in a shared "loose" window anywhere on a
frame.  A loose window is not fixed, it can be deleted at any time and
will be recreated when a message shall be shown or a question asked.

(3) Put minibuffer and echo in separate, loose windows anywhere on a
frame.  Both windows can be deleted where the minibuffer window is
deleted automatically when the dialog with the user has terminated.

Hence, the term loose refers only to the fact that such a window can
be deleted and will be recreated on-the-fly.  Alternatively, we could
call such a window "volatile", "ephemeral" ...  And to indicate that
echos shall appear in a separate window you have to specify a non-nil
'echo-area' frame parameter on top of a 'loose' minibuffer parameter.

Eventually we would allow an arbitrary number of loose minibuffer and
echo windows on a frame, each possibly owned by a separate thread
allowing an arbitrary number of user interactions to go on in
parallel.  But I have not yet digged into all conventions for
minibuffers and echos (naming, synchronicity) and maybe never will.

martin