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

[martin rudalics]

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

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

>> AFAICT the most simple approach appears to restore the Emacs 26
>> behavior for sessions with separate minibuffer frames.
>
> I'm not sure how simple that would be.  Have you a patch to propose?

No.  I think you should trace all 'minibuffer-follows-selected-frame'
related changes and make them pertinent to the value of that variable.
Then people who need the old behavior could get it back by setting that
variable to nil.  It was an unwritten rule of Emacs development that a
new feature that breaks established behavior should be (a) made optional
and (b) by default turned off.  Maybe that rule doesn't apply any more
but at least (a) should be still supported.

>> What would the semantics of 'minibuffer-follows-selected-frame' be for
>> such a session anyway?
>
> I've a vague memory of checking this was OK at the time of the change.
> I can't remember many of the details now, though.

Then please try to remember.  AFAICT 'minibuffer-follows-selected-frame'
should never impact the behavior of separate minibuffer frames.

martin