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

[Eli Zaretskii]

> Date: Mon, 11 Jul 2022 17:15:08 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org,
>   acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > Please don't forget that Emacs is not entirely in control of what
> > happens here: the window manager is also an important part of this
> > dance, and it has its own ideas about which frame should be raised and
> > which should be given focus.  It is unreasonable to expect Emacs to be
> > able to work around every idiosyncratic aspect of the behavior of
> > every window manager, let alone customized by users.
> 
> Perhaps that "sometimes" could be expanded upon.  How is the Lisp hacker
> supposed to know when she's got to raise or focus the frame in addition
> to selecting a window?

The documentation answers that question in the best way we can.

> OK, but that doesn't really address the point I was trying to make.  That
> is, that select-window (and other functions too) should have an
> unambiguous, clear function, which should be unambiguously documented.

select-window _does_ have a well-defined function: it makes the window
the selected window.  That's all.

> Whether select-window raises the frame or not (and you say here not), it
> should _always_ either do it or not do it.  There shouldn't be a
> "sometimes" in the doc.  It is these "sometimes"es which lead to bugs
> like the current one.

Whether select-window also raises the frame and/or redirect focus is
determined by other settings, some of them in Emacs and some of them
outside Emacs.

> OK, so maybe we could agree that select-window ought to move focus onto
> the target frame, but not raise it (modulo fascistic window managers).

Isn't that what happens, at least in the vast majority of cases?

> Then we'd probably want a separate function which does raise that frame.

We already have that: raise-frame.

> My larger point is that all these functionalities, focussing, raising,
> selecting, "highlighting", whatever, seem to be mixed together in the
> code.  If we could separate them into coherent functions, we would have
> fewer bugs like the current one in the future.

I'm not sure it's possible (or even desirable).