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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Sun, Jul 17, 2022 at 10:03:23 -0400, Stefan Monnier wrote:
> > 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.

> But the interactive calls have nil for `norecord`.

Some of them might not.  I don't see how that observation relates to my
quoted paragraph, though.

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

> Currently `norecord` is the flag used to indicate that this is an
> "internal" `select-window` call, typically part of something like
> `with-selected-window` or `save-window-excursion`, which seem like good
> candidates to use the more "bare bones" select-window semantics (whose
> difference in semantics I don't fully comprehend, to be honest, so
> hopefully, this discussion will lead to doc (or at least comment)
> changes to describe those differences).

I was thinking about some primitive such as select_window_no_focus,
and/or select_frame_no_focus (although do_switch_frame pretty much is
this, now).  These would do what s-w and s-f do, but rigorously
refrain from setting the focus, redirecting the focus in any frame,
raising a frame, and so on.

> There might indeed be other calls to `select-window` that specify the
> `norecord` arg for some other reason, so maybe linking the two that
> way is not a good idea, I don't know.

I think it is a fundamentally bad idea.  There's no conceptual
connection between recording a position in a window list and changing a
window manager's focus.

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

> Yes, I didn't mean to say they didn't exist, just that I wasn't able
> to see them.

OK.

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

> As you might know, I'm in that same boat :-)

Ah, good.  ;-)  Are you able and willing to formalise bugs in this area,
so that we can set about eradicating them?  As you know, I only rarely
run Emacs on a window manager.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).