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

[Alan Mackenzie]

Hello, Martin.

On Mon, Jul 11, 2022 at 09:45:59 +0200, martin rudalics wrote:
>  > Thanks!  I use xfce, too.  But I haven't changed anything here away from
>  > its default.  I run Emacs on a tty anyway.

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

>  >> Now note that when in my scenario I type C-x C-c, the minibuffer frame
>  >> is selected and has focus.

>  > But not raised, though?  Surely the MB frame being selected and having
>  > focus is what we want, so that we can type "yes" or "no" next.

> With "when" I meant "at the time" I type C-x C-c.

Sorry for the misunderstanding.

>  > Try running GDB in an Emacs on a Linux tty.  That's what I do anyway.  I
>  > seem to remember watching the focus, last time I did this, a day or two
>  > ago.

> I have no experience with running GDB from anywhere but Emacs itself.
> IIRC Linux ttys are full-screen, so where would my Emacs frames fit in?

The GDB Emacs is on a tty, in a single frame.  The frames of the target
Emacs can be on X Windows.  (Or in another tty.)  So you would start the
target Emacs in X, note its process-id with ps a, start  gdb in the tty
Emacs, then do attach <proc-id>, and carry on as usual.  When you reach
a breakpoint, the X session appears to hang, at which point you type
<ctrl>-<alt>-<F4> (for example) to get to the Emacs and GDB.  When you
type continue in GDB, you then return to X with (e.g.) <alt>-<F7>.  It's
not as cumbersome as it sounds.

>  > Anyway, we'll have to decide soon what to do for Emacs 28.2.  The
>  > first pretest is already out there.  What we do needs to be simple
>  > and safe.  The alternatives so far seem to be do nothing, apply the
>  > 53-line deletion from master (which Eli has already rejected) or
>  > apply my patch above (fixed to work with tty's).  At the moment, I
>  > would favour the last of these.

> For Emacs 28.2 I could imagine something like

> diff --git a/src/frame.c b/src/frame.c
> index 0c278259a7..27442ee120 100644
> --- a/src/frame.c
> +++ b/src/frame.c
> @@ -1499,7 +1499,8 @@ do_switch_frame (Lisp_Object frame, int track, int 
> for_deletion, Lisp_Object nor
>   #else /* ! 0 */
>     /* Instead, apply it only to the frame we're pointing to.  */
>   #ifdef HAVE_WINDOW_SYSTEM
> -  if (track && FRAME_WINDOW_P (f) && FRAME_TERMINAL (f)->get_focus_frame)
> +  if (track && NILP (Vinhibit_redisplay)
> +      && FRAME_WINDOW_P (f) && FRAME_TERMINAL (f)->get_focus_frame)
>       {
>         Lisp_Object focus, gfocus;

> that is use the analogous unpleasant hack from resize_mini_window.

I tried it out.  It appears to work.  :-)

>  > select-window and select-frame should NOT move the focus.

> I'd like to agree with you but implementing it is virtually impossible.
> Emacs would probably stop working immediately.  Just try to tell people
> that 'select-window' will not give input focus to a window only because
> it happens to reside on another frame.

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

>  > select-frame is even documented (in the Elisp manual) not to do
>  > this.  That documentation is not true for Emacs 28.x, but may now
>  > have become true in master since I removed those 53 lines from
>  > do_switch_frame, but I'm not sure.

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

> 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?  Perhaps we would also need a (new) function which would
just make the struct window * current for manipulation without it being
displayed on the screen.

That would give us two unambiguously distinct functions for windows, in
the same way we have (ought to have) select-frame-set-input-focus and
select-frame for frames.  Here I advocate amending select-frame such
that it _never_ grabs the focus.  (Assuming I haven't done that already
with that 53-line patch.)

>  >> Unfortunately, it breaks C-x o.  Try with my scenario but instead of
>  >> answering the 'yes-or-no-p' question type C-x o.  With Emacs 28.1 this
>  >> selects the window on top of the normal frame.  With current master it
>  >> does nothing.

>  > I don't think that's true.  It selects the other window on the normal
>  > frame (which is the selected frame), but retains the focus in the
>  > minibuffer frame (the focus being redirected from the normal frame).

> Indeed.  Which means that it contradicts the Elisp manual which says
> about 'select-window' that

>    This function makes WINDOW the selected window and the window
>    selected within its frame, and selects that frame.

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?

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?

>  >> It doesn't even tell me that there is no other window to select.  So
>  >> this cure is certainly worse than the disease.

>  > I think that might be over-stating things.  Most of the time, users are
>  > just going to be typing "yes" or "no" here.

> Then with

> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

> select the "normal" frame and type C-h f.  In the minibuffer frame now
> type C-x o.  This always used to select _and_ focus the window on the
> normal frame and would be needed, for example, to fetch the name of the
> function to describe from the normal window.

Surely C-x o shouldn't move the focus to a different frame?  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 the behavior described in the comment your patch elided as

>    /* If a frame's focus has been redirected toward the currently
>       selected frame, we should change the redirection to point to the
>       newly selected frame.  This means that if the focus is redirected
>       from a minibufferless frame to a surrogate minibuffer frame, we
>       can use `other-window' to switch between all the frames using
>       that minibuffer frame, and the focus redirection will follow us
>       around.  */

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.

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

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

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).