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

[Alan Mackenzie]

Hello, Martin.

On Tue, Jul 12, 2022 at 09:35:00 +0200, martin rudalics wrote:

[ .... ]

>  > Apologies: the doc string for select-window virtually says it grabs
>  > the focus.  Couldn't we go the whole way, and explicitly state that
>  > select-window is really "select-window-set-input-focus"?

> But we can't guarantee that.  Popping up a new frame via
> 'pop-to-buffer' should do that via 'select-frame-set-input-focus'.  But
> if the window manager forbids focus stealing, it doesn't.  The new
> frame may even come up totally obscured.

>  >> The Elisp manual is controversial about this.  A sentence like

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

> The text mirrors the savage wilderness of GUIs - eat and be eaten.
> That's not the clean, well-lighted environment of a tty.

Doesn't terminfo cater for this sort of thing?  Whether it does or not,
surely we could set up a set of capability variables, nil/t, a bit like
we've got focus-follows-mouse.

[ .... ]

> 'display-buffer', for example, should not select the window it uses.
> But if you display the buffer in a new frame and the window manager
> decides to always give focus to a new frame, that window will be
> selected.  It took me years to convince Drew that Emacs can't do
> anything about that.

Again, where are our capability variables?

> It would help if we had APIs that left the choice whether a new frame
> should receive focus or be raised to the application.  I've never seen
> one that does that.  (Rightfully so - think of applications that within
> milliseconds ask for moving focus from one window to another and back.)

I'm thinking of one at the moment.  ;-(

[ .... ]

>  > Yes.  :-(  But that (normal) frame _is_ selected.  It's just that
>  > its focus has been redirected to the minibuffer frame.  Normally,
>  > C-x o doesn't move the focus away from the currently focussed frame.

>  >> and about the window “selected within the frame”

>  >>     For the selected frame, that window is called the “selected
>  >>     window”—the one in which most editing takes place, and in which
>  >>     the cursor for selected windows appears

>  >> Here the cursor for the selected window appears in the minibuffer
>  >> frame window and that's what fooled me.  In which window should the
>  >> cursor appear in your opinion?

>  > In the focussed frame, in the selected window in it.  That would be
>  > in the minibuffer window, surely?

> But that's not the selected window which is, according to what you say
> above, the selected window of the normal frame.

>  > I don't think the documentation in the Elisp manual quite covers
>  > complexities like MB-only frames and focus redirection.  Surely C-x
>  > o shouldn't move the focus to a different frame?

> When the minibuffer is active it should (even if it does not succeed in
> all cases) because 'other-window' calls 'select-window'.

>  > Surely C-x o shouldn't move the focus to a different frame?

> It did so ever since the code you elided was written.

C-x o calls next-window and the spec for that, with arguments like
ALL-FRAMES and MINIBUF is right on the boundaries of understandability.

>  > Here the user would have C-x 5 o to move to that normal frame.  Any
>  > user chosing a minibuffer-only frame setup (for whatever advantages)
>  > should be aware of things like that.

> This is not only about minibuffer-only frame setups.  It can happen
> whenever a frame without minibuffer is made.  The underlying idea is
> that navigation within the cyclic ordering of windows should be
> coherent regardless of where the minibuffer window resides.

>  > That's a terrible piece of writing.  The "using" could mean either
>  > of "switch between all the frames which use that MB frame" or
>  > "switch between all the frames by using the minibuffer frame as a
>  > mechanism".

>  > I still can't make sense out of that comment.  But the code it was
>  > attached to caused the new frame to grab the focus, and that was
>  > what happened in the bug scenario.  In fact there, the redirection
>  > of the new frame (the normal frame) was left pointing at itself.

> You're barking at the wrong tree.  That code worked well for half of
> its lifetime.

It strikes me it was really fragile code.  In the middle of the function
to switch the current frame there was a difficult to understand ad-hoc
section which redirected the focus, sometimes.  Surely that should be
done somewhere else (where?) more systematically.

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

I think we can understand the motivation behind that.  Fselect_window
will surely do everything to keep everything consistent and coherent.
Just setting the variable is liable to lead to inconsistency and chaos if
you're not very careful what you do.  This pattern is not unknown in
Emacs, where a high-level function (or command, even) wants to do things
which are inconvenient at the nitty-gritty level.  I don't recall seeing
any comments about Fselect_window saying "be careful!".

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

What is stopping you fixing it, given that you understand it better than
anybody else?

> Making the minibuffer follow the selected frame was just the final
> stab.

That's optional: now, either the MB follows the selected frame or it
doesn't.

>  >> If we were to change that, we would change the entire cyclic
>  >> ordering of windows concept which explicitly states that "If the
>  >> minibuffer is active, the minibuffer window is included too" and
>  >> that window may reside on any frame.

Yes.  :-(

>  > If we change all this (and I think we should), we should do it in a
>  > way which doesn't disturb the cyclic ordering.

> We should eliminate the original sin and be done with it once and for
> all.

Commit 6355802033d202....aecceef?  Why not?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).