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

[Alan Mackenzie <acm@muc.de>]

Hello, Martin.

On Thu, Jul 07, 2022 at 09:55:18 +0200, martin rudalics wrote:
>  > An idea I had on Sunday was to forcibly set the window system focus
>  > to the minibuffer frame just before the recursive edit in
>  > read_minibuf, though I didn't post a patch for it.  This appears to
>  > work for me.

> This will still raise the minibuffer frame above the normal frame if
> your window manager uses a "Raise on focus" policy.  So it's not any
> different from using 'select-frame-set-input-focus' here.

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.

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

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

The state we're in at the moment is that the cause of the bug has been
tentatively identified and a fix proposed (see one of my posts from
yesterday).  This fix would be too risky for the release branch, so we
need a "safe" workaround for that branch.

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

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).