bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame

[Alan Mackenzie <acm@muc.de>]

Hello again, Martin.

On Fri, Jul 08, 2022 at 10:55:07 +0000, Alan Mackenzie wrote:
> On Fri, Jul 08, 2022 at 09:01:43 +0200, martin rudalics wrote:
> >  > I don't follow.  If the WM does "Raise on focus", surely it will
> >  > raise the frame no matter how it acquires the focus.  Such focus is
> >  > here essential for the working of the minibuffer.

> > It should not deliberately raise a frame that already has focus.

> OK.  We could add an extra check for the frame already having the focus.
> Is there anything else suboptimal about that proposed fix to emacs-28?

> >  > Is it not the case that acquiring the focus with Fx_focus_frame
> >  > would be better than not doing so?

> > It does not restore the Emacs 26 behavior.

How, precisely, does the behaviour in my proposed patch differ from that
of Emacs 26?

> > If you look at the reports for Bug#8856, Bug#11566 or Bug#11939, you
> > might be able to imagine how much time I spent to get the behavior
> > right for Drew's setup back then.  It's quite sobering to see my
> > efforts from that period get wasted now.

What do you mean by "wasted"?  What fails to work now which worked
immediately after your fixes for these three bugs?

> .... I'll take a look at these bug reports this evening.

I've had a look at those bugs, now, albeit briefly.  They do not contain
concise recipes for reproducing the bugs, and anyway, I don't have a
Windows system to try things out on.  They are bugs where the focus
ended up on the wrong frame, and it was hypothesised that this may have
been because of Windows always giving the focus to newly created frames.

[ .... ]

> > martin

-- 
Alan Mackenzie (Nuremberg, Germany).