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

From: Alan Mackenzie <[email-masked]>
Date: Sun, 3 Jul 2022 16:09:43 +0000

Hello, Martin and Eli.

On Sun, Jul 03, 2022 at 10:16:04 +0200, martin rudalics wrote:
>  > I don't understand why the current bug is happening; focus switching in
>  > Emacs is complicated.  However, the following patch is, at least, a
>  > workaround for the problem.  Should I commit it?

> At least here this raises the minibuffer frame above the normal frame
> which may obscure the contents of the *Process List* window and thus
> again force the user to use the mouse or a window manager shortcut.

OK.  How about using Fx_focus_frame instead?  (No, I don't know what to
give the function for NOACTIVATE.).  This, however, would still just be
a workaround.

> In either case, it's not how Emacs 26 and Emacs 28.1 behaved.  The
> correct behavior is to make sure that the minibuffer frame is selected
> and gets keyboard input while the normal frame remains fully visible.

I don't think that's relevant.  At the time the recursive edit for the
minibuffer is started, the minibuffer frame IS the selected frame.  It
just doesn't have the window-manager focus.

I've managed to track down the cause of this, partly, i.e. it's the
change to gui_consider_frame_title (xdisp.c) where the trouble's
happening.  More particularly, it's in unwind_format_mode_line, L34,
where there's:

	Fselect_window (old_window, Qt);

..  If this line is commented out, the problem doesn't happen.

But select-window is not meant to move the focus, is it?  This is not
mentioned in the doc string (Not even "This function doesn't affect the
window-manager focus"), and it possibly should be.

While debugging, is there any easy way of determining which frame
currently has the focus?  This would make it far easier to work out
what's going on.

At the moment, I think that the workaround with Fx_focus_frame, if it
works, might be the best fix for Emacs 28.2.  But there's a deeper
problem buried here somewhere, which ought to be fixed properly in
master.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).