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

[Robert Marshall]

Gregory Heytings writes:
 > 
 > >
 > > I've been finding - in last 12 months - that sometimes when I do M-x and 
 > > type something the cursor has moved to the main window in that frame, 
 > > and the desired command ends up in that window if it is a 'normal' 
 > > buffer or does more drastic things if (for example) in dired.
 > >
 > > from Ch l in one of these cases
 > > <escape> <select-window> x          ;; execute-extended-command
 > > ;; handle-select-window
 > > g                                   ;; revert-buffer
 > > n                                   ;; dired-next-line
 > > u                                   ;; dired-unmark
 > > s                                   ;; dired-sort-toggle-or-edit
 > >
 > > you'll see that my intention of typing M-x gnus has been subverted and 
 > > the commands are happening in a dired buffer!
 > >
 > > I have (setq mouse-autoselect-window 1) but I don't think I'm pausing 
 > > long enough (and it doesn't see to kick in anyway from a minibuffer) 
 > > that handle-select-window is clearly the problem but not sure where it 
 > > is coming from, and it is happening very rarely so I'd prefer not to set 
 > > a break there.
 > >
 > 
 > Thanks for your bug report.  I could not reproduce what you describe alas; 
 > could you perhaps try to create a recipe, starting with emacs -Q, with 
 > which the bug you experience is triggered?
 > 

I will attempt to - however I'm only seeing this behaviour once a week
or so, so difficult to replicate. My impression is that it used to
happen more frequently when I was running a build from git made spring
2020, it's now less frequent but still occurring.

I shall steer clear of functions starting with the characters dxyes -
that way lies data loss with this bug and a dired buffer ;)

Robert
-- 
Robert Marshall               twitter: @rajm