bug#47969: 28.0.50; Losing minibuffer focus in trying M-x command

[martin rudalics <rudalics@gmx.at>]

 >> Indeed, with that understanding there is no contradiction.  But what
 >> "autoselection [...] never unselects the minibuffer if it is active" means
 >> in practice is that autoselection is disabled while the minibuffer is
 >> active.  If you M-x, move the mouse to another window, type a command and
 >> RET, no autoselection happens.  I'm not sure that the complexity of what
 >> you suggest is worth the price for this specific case (ESC x instead of
 >> M-x), given what the behavior is with M-x.
 >
 > I'm not sure either, but let's hear Martin at least, and I hope Lars
 > as well, on that idea.

I have no good idea here but note one aspect: When a user has the
minibuffer on a separate frame and her WM does focus-follows-mouse,
moving the mouse between frames will select another window.  I doubt
that we can impose any restrictions for minibuffer dialogues in such
case so we have an inconsistency.

Basically, it all boils down to whether we want our minibuffer
interactions be modal or not.  I sometimes start a dialogue and, in
order to finish it, look into some other buffer and maybe even start
some recursive dialogue before returning to the prior one.  While doing
that I probably would like autoselection to behave as usual.  OTOH a
strictly modal dialogue like `yes-or-no-p' should probably disallow
autoselection.

martin