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

[Gregory Heytings <gregory@heytings.org>]

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

Are you sure?  I just tried it (I enabled focus-follows-mouse in both my 
WM and Emacs and mouse-autoselect-window in Emacs), and with Emacs 25 
(i.e. before 3fdd3bb56c) and with Emacs 28 with my patch, moving the mouse 
between ESC and x, or even later, does not select another window.  The 
user input is redirected to the minibuffer, even when it is not the 
currently selected frame by the WM.

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

Is autoselection really necessary?  An click does the job in this case: 
the window in which the click happened is selected, and the minibuffer is 
suspended.