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

[Alan Mackenzie]

Hello, Stefan.

On Sat, Jul 16, 2022 at 19:39:10 -0400, Stefan Monnier wrote:
> > You're barking at the wrong tree.  That code worked well for half of its
> > lifetime.  What really got us into the present bredouille was commit
> > 6355802033d202c63f6fff4b77bf2b0c7aecceef and its ill-fated decision to
> > call Fselect_window instead of directly setting selected frame and
> > window as the well-established and tested code in display_mode_lines
> > did and still does.

> In case you intend to fix this apparent blunder of mine: the point of
> that commit was to set the selected window and frame so that ELisp code
> run from the `mode-line-format` would see meaningful and consistent
> values of selected-frame/window (and companions like the
> frame-selected-window of the selected-frame, ...).

Yes, like I guessed in my post yesterday in this thread.

> If calling `Fselect_window` with a non-nil `norecord` argument messes
> things up somehow then maybe we should fix `Fselect_window` accordingly,
> or otherwise provide a "more bare bones" function that DTRT.

I would be in favour of the "more bare bones" function.  Fselect_window
is pretty much a command, and does far too much (including sometimes
shifting the focus) for an internal low-level function.  It's doc string
is incomplete in this regard, and its entry in the Elisp manual is vague
and shifty.

Fselect_frame (or more precisely do_switch_frame) is a place where the
trouble occurs, or certainly was before my removal of the 53 lines focus
redirecting/shifting code ~10 days ago.  That removed code seems to be
needed for correct frame switching with a minibuffer-only frame, but in
the middle of do_switch_frame doesn't seem to be the optimal place for
it.

> It seems clear to me, for example, that when called with a non-nil
> `norecord` (like in the mode-line code), `Fselect_window` should never
> cause any change to the focus redirection (or the focus itself).
> And neither should it call things like `resize_mini_window`, I think.

It would be a mistake to couple focus switching with NORECORD, something
which is only coincidentally tied to the focus.

> > In the sequel, obscure bugs began to pile up, all very difficult to
> > describe and reproduce (Bug#23124, Bug#24285, Bug#34317) and were fixed
> > with some trickery.  The origin of all that evil remained in place.

> I can't see the connection between these bugs at the above commit, sorry.

Neither can I, but Martin's spent quite a few years analysing these
things.  The mechanisms of these bugs, and their connection with that
2008 patch are likely involved and complicated.

The current state of affairs is that Emacs 28 is unusable to some people
who prefer a separate minibuffer frame (in particular, Drew Adams) and
it may well be worth our while to identify the current bugs and fix
them.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).