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

[Alan Mackenzie]

Hello, Eli.

On Mon, Jul 11, 2022 at 19:43:11 +0300, Eli Zaretskii wrote:
> > Date: Mon, 11 Jul 2022 16:22:21 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
> >   56305@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > So you implemented 'minibuffer-follows-selected-frame' despite the fact
> > > that multiple frames hardly make sense on your usual setup?

> > That's not a fact.  I typically run with several/many frames on my tty.
> > Six, or even nine, is not uncommon.  I switch between them using the
> > <Fn> keys.  The minibuffer not staying in "its own" frame was annoying
> > me quite a bit.

> I hope you'll agree that focus redirection is not very relevant to TTY
> frames.  There, the top-most frame is the only one visible, and by
> definition it has the focus.

I think we're in violent agreement here.

> > >    Note that sometimes selecting a window is not enough to show it, or
> > >    make its frame the top-most frame on display: you may also need to
> > >    raise the frame or make sure input focus is directed to that frame.

> > That sounds like the text from a bug report.  Selecting a window should
> > either do all these GUI things, or it shouldn't do them.  "Sometimes"
> > feels like an apology for failing to fix a bug before a release.

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

> > > wouldn't make sense if in a majority of cases selecting a window
> > > would _not_ also raise its frame and direct input focus to it.

> > So why can't we make select-window _always_ raise its frame and get
> > input focus?

> Because it's wrong!  If I want to type into a window, it does NOT mean
> I want that window's frame raise!  Imagine a situation where I look at
> some text in one frame and type something into another frame: I can
> legitimately want to see all of the text I'm reading, but only a small
> portion of the text into which I'm writing.

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

> Automatically raising a frame in this case would be an annoyance, since
> each time I move the focus into the "typing" frame, it would raise and
> obscure my "reading" frame.

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).
Then we'd probably want a separate function which does raise that 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.

-- 
Alan Mackenzie (Nuremberg, Germany).