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

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

[martin rudalics]

With emacs -Q --load "~/mini.el" which contains the three lines

(setq use-dialog-box nil)
(setq default-frame-alist '((minibuffer . nil)))
(shell)

and type C-x C-c in the minibuffer frame.  This asks a 'yes-or-no-p'
question in the minibuffer frame but selects the *Process List* window
on the other frame.

FWICT this worked correctly until Emacs 26, was broken in Emacs 27,
returned to work in Emacs 28.1 and is now broken on both, release and
master branch, again.


In GNU Emacs 29.0.50 (build 10, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)
  of 2022-06-29 built on restno
Repository revision: 60af986f38e98fde3e17005e49d175c061a1a29a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

Configured using:
  'configure --with-gif=ifavailable --with-tiff=ifavailable
  --with-gnutls=no --without-pop --enable-gcc-warnings=warn-only
  --enable-checking=yes,glyphs --enable-check-lisp-object-type=yes
  'CFLAGS=-O0 -g3 -no-pie -Wno-missing-braces''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GSETTINGS HARFBUZZ JPEG LIBSELINUX MODULES
NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND THREADS TOOLKIT_SCROLL_BARS X11
XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
   value of $LANG: de_AT.utf8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 35654 7389)
  (symbols 48 5036 1)
  (strings 32 13288 1313)
  (string-bytes 1 426460)
  (vectors 16 9152)
  (vector-slots 8 144810 8448)
  (floats 8 22 17)
  (intervals 56 212 0)
  (buffers 992 10))

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

[Eli Zaretskii]

> Date: Wed, 29 Jun 2022 19:54:44 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> With emacs -Q --load "~/mini.el" which contains the three lines
> 
> (setq use-dialog-box nil)
> (setq default-frame-alist '((minibuffer . nil)))
> (shell)
> 
> and type C-x C-c in the minibuffer frame.  This asks a 'yes-or-no-p'
> question in the minibuffer frame but selects the *Process List* window
> on the other frame.
> 
> FWICT this worked correctly until Emacs 26, was broken in Emacs 27,
> returned to work in Emacs 28.1 and is now broken on both, release and
> master branch, again.

Alan, could you please look into this?  Emacs 28.2 is about to start
pretest.

Thanks.

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

[Alan Mackenzie]

Hello, Eli.

On Wed, Jun 29, 2022 at 22:10:49 +0300, Eli Zaretskii wrote:
> > Date: Wed, 29 Jun 2022 19:54:44 +0200
> > From: martin rudalics <rudalics@gmx.at>

> > With emacs -Q --load "~/mini.el" which contains the three lines

> > (setq use-dialog-box nil)
> > (setq default-frame-alist '((minibuffer . nil)))
> > (shell)

> > and type C-x C-c in the minibuffer frame.  This asks a 'yes-or-no-p'
> > question in the minibuffer frame but selects the *Process List* window
> > on the other frame.

> > FWICT this worked correctly until Emacs 26, was broken in Emacs 27,
> > returned to work in Emacs 28.1 and is now broken on both, release and
> > master branch, again.

> Alan, could you please look into this?  Emacs 28.2 is about to start
> pretest.

Will do, yes.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Eli and Martin.

On Wed, Jun 29, 2022 at 22:10:49 +0300, Eli Zaretskii wrote:
> > Date: Wed, 29 Jun 2022 19:54:44 +0200
> > From: martin rudalics <rudalics@gmx.at>

> > With emacs -Q --load "~/mini.el" which contains the three lines

> > (setq use-dialog-box nil)
> > (setq default-frame-alist '((minibuffer . nil)))
> > (shell)

> > and type C-x C-c in the minibuffer frame.  This asks a 'yes-or-no-p'
> > question in the minibuffer frame but selects the *Process List* window
> > on the other frame.

> > FWICT this worked correctly until Emacs 26, was broken in Emacs 27,
> > returned to work in Emacs 28.1 and is now broken on both, release and
> > master branch, again.

> Alan, could you please look into this?  Emacs 28.2 is about to start
> pretest.

In your (Martin's) scenario, the yes-or-no-p seems to work just before
the following commit, but goes into an infinite loop after it:

commit dfa3e6f424b20fe27d9041b2ce7d69811df5d8cd
Author: Alan Mackenzie <acm@muc.de>
Date:   Fri May 20 20:18:38 2022 +0000

    Restore the Fselect_window call in gui_consider_frame_title.

There's something suspicious in that commit, namely:

* src/frame.c (do_switch_frame): When the selected window in the target frame
is the mini-window, switch away from this window unless there is a valid
minibuffer there.

Maybe that's a red herring, but it might be relevant.

I'll look at this in more detail tomorrow.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Eli and Martin.

On Wed, Jun 29, 2022 at 22:10:49 +0300, Eli Zaretskii wrote:
> > Date: Wed, 29 Jun 2022 19:54:44 +0200
> > From: martin rudalics <rudalics@gmx.at>

> > With emacs -Q --load "~/mini.el" which contains the three lines

> > (setq use-dialog-box nil)
> > (setq default-frame-alist '((minibuffer . nil)))
> > (shell)

> > and type C-x C-c in the minibuffer frame.  This asks a 'yes-or-no-p'
> > question in the minibuffer frame but selects the *Process List* window
> > on the other frame.

> > FWICT this worked correctly until Emacs 26, was broken in Emacs 27,
> > returned to work in Emacs 28.1 and is now broken on both, release and
> > master branch, again.

> Alan, could you please look into this?  Emacs 28.2 is about to start
> pretest.

At the point in read_minibuf where recursive_edit_1 is called, all the
frame and window variables appear to be in order - things like
minibuf_window, current_buffer, selected_window, selected_frame, ...

What is not in order is the window system focus, which in the bug
scenario is on the "normal" frame rather than the minibuffer frame.  As a
matter of interest, if the C-x C-c command is invoked from the "normal"
frame, things work correctly.

As a matter of interest, when I moved from the "normal" frame to the
minibuffer frame with <alt><tab> (or clicking on the MB frame), there
wasn't the expected call to do_switch_frame ().

I don't understand why the current bug is happening; focus switching in
Emacs is complicated.  However, the following patch is, at least, a
workaround for the problem.  Should I commit it?


diff --git a/src/minibuf.c b/src/minibuf.c
index 0fc7f2caa1..5480d1f2af 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -896,6 +896,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* Ensure that the minibuffer frame has the window-system focus.
+     This is sometimes needed for minibuffer-only frames.  */
+  call2 (Qselect_frame_set_input_focus, mini_frame, Qt);
+
   recursive_edit_1 ();
 
   /* If cursor is on the minibuffer line,


> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

 > I don't understand why the current bug is happening; focus switching in
 > Emacs is complicated.  However, the following patch is, at least, a
 > workaround for the problem.  Should I commit it?

At least here this raises the minibuffer frame above the normal frame
which may obscure the contents of the *Process List* window and thus
again force the user to use the mouse or a window manager shortcut.  In
either case, it's not how Emacs 26 and Emacs 28.1 behaved.  The correct
behavior is to make sure that the minibuffer frame is selected and gets
keyboard input while the normal frame remains fully visible.

martin

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

[Alan Mackenzie]

Hello, Martin and Eli.

On Sun, Jul 03, 2022 at 10:16:04 +0200, martin rudalics wrote:
>  > I don't understand why the current bug is happening; focus switching in
>  > Emacs is complicated.  However, the following patch is, at least, a
>  > workaround for the problem.  Should I commit it?

> At least here this raises the minibuffer frame above the normal frame
> which may obscure the contents of the *Process List* window and thus
> again force the user to use the mouse or a window manager shortcut.

OK.  How about using Fx_focus_frame instead?  (No, I don't know what to
give the function for NOACTIVATE.).  This, however, would still just be
a workaround.

> In either case, it's not how Emacs 26 and Emacs 28.1 behaved.  The
> correct behavior is to make sure that the minibuffer frame is selected
> and gets keyboard input while the normal frame remains fully visible.

I don't think that's relevant.  At the time the recursive edit for the
minibuffer is started, the minibuffer frame IS the selected frame.  It
just doesn't have the window-manager focus.

I've managed to track down the cause of this, partly, i.e. it's the
change to gui_consider_frame_title (xdisp.c) where the trouble's
happening.  More particularly, it's in unwind_format_mode_line, L34,
where there's:

	Fselect_window (old_window, Qt);

..  If this line is commented out, the problem doesn't happen.

But select-window is not meant to move the focus, is it?  This is not
mentioned in the doc string (Not even "This function doesn't affect the
window-manager focus"), and it possibly should be.

While debugging, is there any easy way of determining which frame
currently has the focus?  This would make it far easier to work out
what's going on.

At the moment, I think that the workaround with Fx_focus_frame, if it
works, might be the best fix for Emacs 28.2.  But there's a deeper
problem buried here somewhere, which ought to be fixed properly in
master.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sun, 3 Jul 2022 16:09:43 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 56305@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> While debugging, is there any easy way of determining which frame
> currently has the focus?

Yes, call x_get_focus_frame (or just examine the value of
FRAME_DISPLAY_INFO (f)->x_focus_frame manually).

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

[Alan Mackenzie]

[ Adding Stefan M., because he's had experience of this sort of thing. ]

Hello, Eli, Martin, and Stefan.

On Sun, Jul 03, 2022 at 19:17:21 +0300, Eli Zaretskii wrote:
> > Date: Sun, 3 Jul 2022 16:09:43 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, 56305@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > While debugging, is there any easy way of determining which frame
> > currently has the focus?

> Yes, call x_get_focus_frame (or just examine the value of
> FRAME_DISPLAY_INFO (f)->x_focus_frame manually).

Thank you indeed.  That was very helpful.  I've spent several hours in
gdb since these recent posts.

Quick summary of the problem: On an Emacs with a minibuffer-only frame
(MBF) and a minibuffer-less frame (NF), with MBF selected with focus,
type C-x C-c.  Instead of the focus remaining in MBF, it's moved to NF.

I've pretty much tracked down what is happening, though I don't
understand the last bit.  Line ~71 in do_switch_frame (frame.c) is this:

          Fredirect_frame_focus (gfocus, frame);

At this point in time gfocus is NF and frame is also NF.  NF's frame
focus had earlier been redirected to MBF.  When Fredirect_frame_focus is
executed, NF becomes redirected to itself, and also becomes the focussed
frame (otherwise known as, sort of, the "highlighted frame").  This
becoming the focussed frame is the problem.

A few lines higher up in do_switch_frame, there is a comment which
purports to explain this shifting of the frame focus, namely:

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

I don't understand this at all well.  What it describes is indeed what
happens.  But if NF has been redirected to MBF, that surely means that
when NF is the selected frame with focus, any characters typed will
appear in MBF.  Not the other way around.

What happens to NF's focus, which previously pointed at MBF, is that it
points to NF itself.  This is as described in the comment.  It is wrong.

Surely what the comment should say, and what should happen is that if
there is a frame switch from NF to NF2, then NF2 should become
redirected to MBF.  No?

What am I missing?

Apologies for this post being somewhat dense.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Mon, 4 Jul 2022 19:10:07 +0000
> Cc: rudalics@gmx.at, Stefan Monnier <monnier@iro.umontreal.ca>,
>   56305@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> Quick summary of the problem: On an Emacs with a minibuffer-only frame
> (MBF) and a minibuffer-less frame (NF), with MBF selected with focus,
> type C-x C-c.  Instead of the focus remaining in MBF, it's moved to NF.

I lost you right here: can you explain why what you described isn't
TRT?  I mean, after you typed "C-x C-c", the minibuffer (whether it's
a frame or a window) has completed its job, and focus should return to
the "real" frame, which is NF.  Right?  What am I missing here?

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

[Alan Mackenzie]

Hello, Eli.

On Mon, Jul 04, 2022 at 22:21:59 +0300, Eli Zaretskii wrote:
> > Date: Mon, 4 Jul 2022 19:10:07 +0000
> > Cc: rudalics@gmx.at, Stefan Monnier <monnier@iro.umontreal.ca>,
> >   56305@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > Quick summary of the problem: On an Emacs with a minibuffer-only frame
> > (MBF) and a minibuffer-less frame (NF), with MBF selected with focus,
> > type C-x C-c.  Instead of the focus remaining in MBF, it's moved to NF.

> I lost you right here: can you explain why what you described isn't
> TRT?

After typing C-x C-c, rather than exiting, this particular Emacs
prompts:

    "Active processes exist; kill them and exit anyway? (yes or no) "

on MBF and it opens a window *Process List* on NF.

> I mean, after you typed "C-x C-c", the minibuffer (whether it's a
> frame or a window) has completed its job, and focus should return to
> the "real" frame, which is NF.  Right?  What am I missing here?

After the C-x C-c, and the appearence of the prompt, NF has the focus,
uselessly, instead of MBF.  That means having to do a window-manager
action to get at the prompt.  This is the bug that Martin registered.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Quick summary of the problem: On an Emacs with a minibuffer-only frame
> (MBF) and a minibuffer-less frame (NF), with MBF selected with focus,
> type C-x C-c.  Instead of the focus remaining in MBF, it's moved to NF.

Hmmm... for me `C-x C-c` basically quits Emacs so the focus afterwards
is ... "nowhere"?
What is this `C-x C-c` supposed to do?


        Stefan

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

[Alan Mackenzie]

Hello, Stefan.

On Mon, Jul 04, 2022 at 15:46:05 -0400, Stefan Monnier wrote:
> > Quick summary of the problem: On an Emacs with a minibuffer-only frame
> > (MBF) and a minibuffer-less frame (NF), with MBF selected with focus,
> > type C-x C-c.  Instead of the focus remaining in MBF, it's moved to NF.

> Hmmm... for me `C-x C-c` basically quits Emacs so the focus afterwards
> is ... "nowhere"?
> What is this `C-x C-c` supposed to do?

This particular C-x C-c puts the following prompt into the minibuffer:

    "Active processes exist; kill them and exit anyway? (Yes or no) "

..

The problem is that instead of being in MBF, the focus has moved to NF.,
obstructing the action of typing "yes" or "no".

Martin's directions for this bug are basically:

Start Emacs with $ emacs -Q -l ~/rudalics3.el

where that file contains exactly:


(setq use-dialog-box nil)
(setq default-frame-alist '((minibuffer . nil)))
(shell)

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Mon, 4 Jul 2022 19:43:51 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Quick summary of the problem: On an Emacs with a minibuffer-only frame
> > > (MBF) and a minibuffer-less frame (NF), with MBF selected with focus,
> > > type C-x C-c.  Instead of the focus remaining in MBF, it's moved to NF.
> 
> > I lost you right here: can you explain why what you described isn't
> > TRT?
> 
> After typing C-x C-c, rather than exiting, this particular Emacs
> prompts:
> 
>     "Active processes exist; kill them and exit anyway? (yes or no) "
> 
> on MBF and it opens a window *Process List* on NF.

Sounds right to me: the frame where Emacs presents some important
information has focus.  If you think this is wrong, please tell why.

> > I mean, after you typed "C-x C-c", the minibuffer (whether it's a
> > frame or a window) has completed its job, and focus should return to
> > the "real" frame, which is NF.  Right?  What am I missing here?
> 
> After the C-x C-c, and the appearence of the prompt, NF has the focus,
> uselessly, instead of MBF.

How is Emacs supposed to know that the user wants only to _look_ at
the list of processes in this case?  In general, moving focus to where
the information is sounds right to me.

> That means having to do a window-manager
> action to get at the prompt.  This is the bug that Martin registered.

In the scenario you described, I'm not sure it's a bug.  In general,
when Emacs prompts with a question in the minibuffer frame and
displays some information pertaining to the question in another frame,
it is not completely clear where should the focus be.  E.g., suppose
that the list of processes was so long that it wouldn't fit in one
window-full, and you'd need to scroll it to see all of it -- wouldn't
you want then to have the focus in the frame with the process list?

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

[Alan Mackenzie]

Hello, Eli.

On Tue, Jul 05, 2022 at 05:29:21 +0300, Eli Zaretskii wrote:
> > Date: Mon, 4 Jul 2022 19:43:51 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > Quick summary of the problem: On an Emacs with a minibuffer-only frame
> > > > (MBF) and a minibuffer-less frame (NF), with MBF selected with focus,
> > > > type C-x C-c.  Instead of the focus remaining in MBF, it's moved to NF.

> > > I lost you right here: can you explain why what you described isn't
> > > TRT?

> > After typing C-x C-c, rather than exiting, this particular Emacs
> > prompts:

> >     "Active processes exist; kill them and exit anyway? (yes or no) "

> > on MBF and it opens a window *Process List* on NF.

> Sounds right to me: the frame where Emacs presents some important
> information has focus.  If you think this is wrong, please tell why.

Well, I don't have a firm opinion on this, but yes-or-no-p is an active
function, here.  We always leave the minibuffer as the selected window
for this function, certainly when we've a normal minibuffer in the frame.
Why should it be different when we've got a minibuffer-only frame?

Also, the mechanism by which NF gets the focus in the bug scenario
appears to be random.  When the focus starts out in NF and we do C-x C-c,
the focus moves to MBF.  This is inconsistent.

The place where the randomness takes effect is the 

    Fredirect_frame_focus (gfocus, frame);

in do_switch_frame I drew attention to yesterday.

> > > I mean, after you typed "C-x C-c", the minibuffer (whether it's a
> > > frame or a window) has completed its job, and focus should return to
> > > the "real" frame, which is NF.  Right?  What am I missing here?

> > After the C-x C-c, and the appearence of the prompt, NF has the focus,
> > uselessly, instead of MBF.

> How is Emacs supposed to know that the user wants only to _look_ at
> the list of processes in this case?  In general, moving focus to where
> the information is sounds right to me.

See above.

> > That means having to do a window-manager
> > action to get at the prompt.  This is the bug that Martin registered.

> In the scenario you described, I'm not sure it's a bug.  In general,
> when Emacs prompts with a question in the minibuffer frame and
> displays some information pertaining to the question in another frame,
> it is not completely clear where should the focus be.  E.g., suppose
> that the list of processes was so long that it wouldn't fit in one
> window-full, and you'd need to scroll it to see all of it -- wouldn't
> you want then to have the focus in the frame with the process list?

You might, yes.  But I think the irritation in having to switch frames to
NF to look at the long list will be outweighed by the opposite irritation
of always having to switch frames to MBF to answer "yes" or "no".

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Tue, 5 Jul 2022 15:59:00 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > After typing C-x C-c, rather than exiting, this particular Emacs
> > > prompts:
> 
> > >     "Active processes exist; kill them and exit anyway? (yes or no) "
> 
> > > on MBF and it opens a window *Process List* on NF.
> 
> > Sounds right to me: the frame where Emacs presents some important
> > information has focus.  If you think this is wrong, please tell why.
> 
> Well, I don't have a firm opinion on this, but yes-or-no-p is an active
> function, here.  We always leave the minibuffer as the selected window
> for this function, certainly when we've a normal minibuffer in the frame.
> Why should it be different when we've got a minibuffer-only frame?
> 
> Also, the mechanism by which NF gets the focus in the bug scenario
> appears to be random.  When the focus starts out in NF and we do C-x C-c,
> the focus moves to MBF.  This is inconsistent.
> 
> The place where the randomness takes effect is the 
> 
>     Fredirect_frame_focus (gfocus, frame);
> 
> in do_switch_frame I drew attention to yesterday.

Do you have a suggestion for a change there to improve the behavior?

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

[Alan Mackenzie]

Hello, Eli.

On Tue, Jul 05, 2022 at 19:24:02 +0300, Eli Zaretskii wrote:
> > Date: Tue, 5 Jul 2022 15:59:00 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > After typing C-x C-c, rather than exiting, this particular Emacs
> > > > prompts:

> > > >     "Active processes exist; kill them and exit anyway? (yes or no) "

> > > > on MBF and it opens a window *Process List* on NF.

> > > Sounds right to me: the frame where Emacs presents some important
> > > information has focus.  If you think this is wrong, please tell why.

> > Well, I don't have a firm opinion on this, but yes-or-no-p is an active
> > function, here.  We always leave the minibuffer as the selected window
> > for this function, certainly when we've a normal minibuffer in the frame.
> > Why should it be different when we've got a minibuffer-only frame?

> > Also, the mechanism by which NF gets the focus in the bug scenario
> > appears to be random.  When the focus starts out in NF and we do C-x C-c,
> > the focus moves to MBF.  This is inconsistent.

> > The place where the randomness takes effect is the 

> >     Fredirect_frame_focus (gfocus, frame);

> > in do_switch_frame I drew attention to yesterday.

> Do you have a suggestion for a change there to improve the behavior?

As yet, no.  I am still having trouble understanding the code well
enough.

But there's at least one interesting aspect.  In the Elisp manual page
"Input Focus" appears the following:

       Lisp programs can switch frames temporarily by calling the function
    `select-frame'.  This does not alter the window system's concept of
    focus; rather, it escapes from the window manager's control until that
    control is somehow reasserted.

This is sadly not true - the functions called by that
Fredirect_frame_focus in do_switch_frame do indeed change the window
system's focus - in particular x_frame_rehighlight (in xterm.c).  If we
were to change the code rather than the manual here, I think a fair bit
of confusion would vanish.  But this isn't something for the release
branch.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Eli, Martin and Stefan.

On Tue, Jul 05, 2022 at 19:24:02 +0300, Eli Zaretskii wrote:
> > Date: Tue, 5 Jul 2022 15:59:00 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > After typing C-x C-c, rather than exiting, this particular Emacs
> > > > prompts:

> > > >     "Active processes exist; kill them and exit anyway? (yes or no) "

> > > > on MBF and it opens a window *Process List* on NF.

> > > Sounds right to me: the frame where Emacs presents some important
> > > information has focus.  If you think this is wrong, please tell why.

> > Well, I don't have a firm opinion on this, but yes-or-no-p is an active
> > function, here.  We always leave the minibuffer as the selected window
> > for this function, certainly when we've a normal minibuffer in the frame.
> > Why should it be different when we've got a minibuffer-only frame?

> > Also, the mechanism by which NF gets the focus in the bug scenario
> > appears to be random.  When the focus starts out in NF and we do C-x C-c,
> > the focus moves to MBF.  This is inconsistent.

> > The place where the randomness takes effect is the 

> >     Fredirect_frame_focus (gfocus, frame);

> > in do_switch_frame I drew attention to yesterday.

> Do you have a suggestion for a change there to improve the behavior?

I do now.  I think we should expunge the entire section of code.

I've spent several hours trying to make sense of it, and failed.  The
code section is 30 years old, and Jim Blandy's comment (from 1992)
suggests that the code was inserted to enable movement between frames
using other-window.

That code was written a few months before the new function other-window
was first committed.  The #ifdef 0 made its appearance in 1993, it being
written by Karl Heuer.

My feeling is that the code section became redundant in the early 1990s,
immediately after the introduction of other-frame, but lived on since
nobody could be sure it wasn't needed.

As I said, I don't understand the code section, and my Emacs appears to
run OK without it.  I think we should get rid of it.  Alternatively, if
somebody else can see a purpose for it, maybe we could amend it to leave
that purpose intact and solve Martin's bug #56305 at the same time.

Here's the patch (based on master) I propose should be committed,
possibly experimentally.  Comments would we welcome:



diff --git a/src/frame.c b/src/frame.c
index c21461d49f..f9e4b2a0e2 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1477,59 +1477,6 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
   else if (f == sf)
     return frame;
 
-  /* 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.  */
-#if 0
-  /* This is too greedy; it causes inappropriate focus redirection
-     that's hard to get rid of.  */
-  if (track)
-    {
-      Lisp_Object tail;
-
-      for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
-	{
-	  Lisp_Object focus;
-
-	  if (!FRAMEP (XCAR (tail)))
-	    emacs_abort ();
-
-	  focus = FRAME_FOCUS_FRAME (XFRAME (XCAR (tail)));
-
-	  if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
-	    Fredirect_frame_focus (XCAR (tail), frame);
-	}
-    }
-#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)
-    {
-      Lisp_Object focus, gfocus;
-
-      gfocus = FRAME_TERMINAL (f)->get_focus_frame (f);
-      if (FRAMEP (gfocus))
-	{
-	  focus = FRAME_FOCUS_FRAME (XFRAME (gfocus));
-	  if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
-	      /* Redirect frame focus also when FRAME has its minibuffer
-		 window on the selected frame (see Bug#24500).
-
-		 Don't do that: It causes redirection problem with a
-		 separate minibuffer frame (Bug#24803) and problems
-		 when updating the cursor on such frames.
-	      || (NILP (focus)
-		  && EQ (FRAME_MINIBUF_WINDOW (f), sf->selected_window)))  */
-	    Fredirect_frame_focus (gfocus, frame);
-	}
-    }
-#endif /* HAVE_X_WINDOWS */
-#endif /* ! 0 */
-
   if (!for_deletion && FRAME_HAS_MINIBUF_P (sf))
     resize_mini_window (XWINDOW (FRAME_MINIBUF_WINDOW (sf)), 1);
 


-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Wed, 6 Jul 2022 17:04:40 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org,
>   acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > Do you have a suggestion for a change there to improve the behavior?
> 
> I do now.  I think we should expunge the entire section of code.

I'm okay with doing that on master, but who will tell us what will
that do for Emacs 28?  I hoped to be able to release Emacs 28.2
soon-ish, so I don't want to wait for this change to collect enough
trust so that we could cherry-pick it.

I guess that means Emacs 28.2 will have this issue unresolved, unless
someone comes up with some ideas.

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

[Alan Mackenzie]

Hello, Eli and Martin.

On Wed, Jul 06, 2022 at 20:29:10 +0300, Eli Zaretskii wrote:
> > Date: Wed, 6 Jul 2022 17:04:40 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org,
> >   acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > Do you have a suggestion for a change there to improve the behavior?

> > I do now.  I think we should expunge the entire section of code.

> I'm okay with doing that on master, but who will tell us what will
> that do for Emacs 28?  I hoped to be able to release Emacs 28.2
> soon-ish, so I don't want to wait for this change to collect enough
> trust so that we could cherry-pick it.

I think I will wait a day and see if Martin or Stefan or anybody else
has anything more to say about it.

> I guess that means Emacs 28.2 will have this issue unresolved, unless
> someone comes up with some ideas.

An idea I had on Sunday was to forcibly set the window system focus to
the minibuffer frame just before the recursive edit in read_minibuf,
though I didn't post a patch for it.  This appears to work for me.

It would look something like this:



diff --git a/src/minibuf.c b/src/minibuf.c
index 0fc7f2caa1..7723167d4d 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -896,6 +896,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* Ensure that the minibuffer frame has the window-system focus.
+     This is sometimes needed for minibuffer-only frames.  */
+  Fx_focus_frame (mini_frame, Qt);
+
   recursive_edit_1 ();
 
   /* If cursor is on the minibuffer line,



-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> > > Do you have a suggestion for a change there to improve the behavior?
>> > I do now.  I think we should expunge the entire section of code.

FWIW, I totally agree.  I'm far from sure that the result will be what
we want, but I think that in case it's not we will then know better what
it is that we want and we'll be in a better position to find
a good solution.

>> I guess that means Emacs 28.2 will have this issue unresolved, unless
>> someone comes up with some ideas.
> An idea I had on Sunday was to forcibly set the window system focus to
> the minibuffer frame just before the recursive edit in read_minibuf,
> though I didn't post a patch for it.  This appears to work for me.

Not sure if "Fx_focus_frame (mini_frame, Qt)" is The Right solution
in the sense that it may fail to correctly set the accompanying
redirection from the "original" frame.

But it seems like a good stop-gap for `emacs-28`, yes.  I'd recommend we
try not to use it in `master` (where we could instead check that the
mini_frame has the focus and drop into the debugger if not to try and
figure out what can cause such a situation).


        Stefan

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

[Andreas Schwab]

On Jul 06 2022, Alan Mackenzie wrote:

> diff --git a/src/minibuf.c b/src/minibuf.c
> index 0fc7f2caa1..7723167d4d 100644
> --- a/src/minibuf.c
> +++ b/src/minibuf.c
> @@ -896,6 +896,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>    /* Don't allow the user to undo past this point.  */
>    bset_undo_list (current_buffer, Qnil);
>  
> +  /* Ensure that the minibuffer frame has the window-system focus.
> +     This is sometimes needed for minibuffer-only frames.  */
> +  Fx_focus_frame (mini_frame, Qt);

Can't this steal focus from unrelated windows?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Alan Mackenzie]

Hello, Andreas.

On Wed, Jul 06, 2022 at 20:58:22 +0200, Andreas Schwab wrote:
> On Jul 06 2022, Alan Mackenzie wrote:

> > diff --git a/src/minibuf.c b/src/minibuf.c
> > index 0fc7f2caa1..7723167d4d 100644
> > --- a/src/minibuf.c
> > +++ b/src/minibuf.c
> > @@ -896,6 +896,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
> >    /* Don't allow the user to undo past this point.  */
> >    bset_undo_list (current_buffer, Qnil);

> > +  /* Ensure that the minibuffer frame has the window-system focus.
> > +     This is sometimes needed for minibuffer-only frames.  */
> > +  Fx_focus_frame (mini_frame, Qt);

> Can't this steal focus from unrelated windows?

Not obviously.  We're about to run the recursive edit for read_minibuf,
so the frame with the mini-window should have the focus anyway.

The only possibility of theft that I see is if a normal frame already
has its focus redirected to a minibuffer frame.  In that case the normal
frame will lose focus.

I don't think this will happen, or if it does, it won't be serious.

> -- 
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Andreas Schwab]

On Jul 06 2022, Alan Mackenzie wrote:

> Not obviously.  We're about to run the recursive edit for read_minibuf,
> so the frame with the mini-window should have the focus anyway.

Does it?  I don't see why Emacs must be in the foreground when it wants
to read from the minibuffer.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Alan Mackenzie]

Hello, Andreas.

On Wed, Jul 06, 2022 at 21:09:32 +0200, Andreas Schwab wrote:
> On Jul 06 2022, Alan Mackenzie wrote:

> > Not obviously.  We're about to run the recursive edit for read_minibuf,
> > so the frame with the mini-window should have the focus anyway.

> Does it?  I don't see why Emacs must be in the foreground when it wants
> to read from the minibuffer.

Ah right - a different program might have the focus, and a user typing
into that other program would suddenly find herself typing into the
Emacs minibuffer instead.  This isn't ideal.

Maybe there's some way of testing whether some Emacs frame has the focus
before executing Fx_focus_frame, and if not, not executing
Fx_focus_frame.

> -- 
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

 > An idea I had on Sunday was to forcibly set the window system focus to
 > the minibuffer frame just before the recursive edit in read_minibuf,
 > though I didn't post a patch for it.  This appears to work for me.

This will still raise the minibuffer frame above the normal frame if
your window manager uses a "Raise on focus" policy.  So it's not any
different from using 'select-frame-set-input-focus' here.

AFAICT the most simple approach appears to restore the Emacs 26 behavior
for sessions with separate minibuffer frames.  What would the semantics
of 'minibuffer-follows-selected-frame' be for such a session anyway?

martin

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

[Alan Mackenzie]

Hello, Martin.

On Thu, Jul 07, 2022 at 09:55:18 +0200, martin rudalics wrote:
>  > An idea I had on Sunday was to forcibly set the window system focus
>  > to the minibuffer frame just before the recursive edit in
>  > read_minibuf, though I didn't post a patch for it.  This appears to
>  > work for me.

> This will still raise the minibuffer frame above the normal frame if
> your window manager uses a "Raise on focus" policy.  So it's not any
> different from using 'select-frame-set-input-focus' here.

I don't follow.  If the WM does "Raise on focus", surely it will raise
the frame no matter how it acquires the focus.  Such focus is here
essential for the working of the minibuffer.

Is it not the case that acquiring the focus with Fx_focus_frame would be
better than not doing so?

> AFAICT the most simple approach appears to restore the Emacs 26
> behavior for sessions with separate minibuffer frames.

I'm not sure how simple that would be.  Have you a patch to propose?

The state we're in at the moment is that the cause of the bug has been
tentatively identified and a fix proposed (see one of my posts from
yesterday).  This fix would be too risky for the release branch, so we
need a "safe" workaround for that branch.

> What would the semantics of 'minibuffer-follows-selected-frame' be for
> such a session anyway?

I've a vague memory of checking this was OK at the time of the change.
I can't remember many of the details now, though.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Eli.

On Wed, Jul 06, 2022 at 20:29:10 +0300, Eli Zaretskii wrote:
> > Date: Wed, 6 Jul 2022 17:04:40 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org,
> >   acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > Do you have a suggestion for a change there to improve the behavior?

> > I do now.  I think we should expunge the entire section of code.

> I'm okay with doing that on master, ....

OK, I've committed that patch to master, removing that section of code.

> .... but who will tell us what will that do for Emacs 28?  I hoped to
> be able to release Emacs 28.2 soon-ish, so I don't want to wait for
> this change to collect enough trust so that we could cherry-pick it.

> I guess that means Emacs 28.2 will have this issue unresolved, unless
> someone comes up with some ideas.

The situation on the release branch is still fluid.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Andreas.

On Wed, Jul 06, 2022 at 21:09:32 +0200, Andreas Schwab wrote:
> On Jul 06 2022, Alan Mackenzie wrote:

> > Not obviously.  We're about to run the recursive edit for read_minibuf,
> > so the frame with the mini-window should have the focus anyway.

> Does it?  I don't see why Emacs must be in the foreground when it wants
> to read from the minibuffer.

How about this, then?  It's not perfect, since the test and the focus
setting aren't atomic, but it should work OK at human speeds, shouldn't
it?



diff --git a/src/minibuf.c b/src/minibuf.c
index 0fc7f2caa1..71fd62cede 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -896,6 +896,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* If some Emacs frame currently has the window-system focus, give
+     it to the minibuffer frame.  This is sometimes needed for
+     minibuffer-only frames.  */
+  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame)
+    Fx_focus_frame (mini_frame, Qt);
+
   recursive_edit_1 ();
 
   /* If cursor is on the minibuffer line,


> -- 
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> diff --git a/src/minibuf.c b/src/minibuf.c
> index 0fc7f2caa1..71fd62cede 100644
> --- a/src/minibuf.c
> +++ b/src/minibuf.c
> @@ -896,6 +896,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>    /* Don't allow the user to undo past this point.  */
>    bset_undo_list (current_buffer, Qnil);
>  
> +  /* If some Emacs frame currently has the window-system focus, give
> +     it to the minibuffer frame.  This is sometimes needed for
> +     minibuffer-only frames.  */
> +  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame)
> +    Fx_focus_frame (mini_frame, Qt);
> +
>    recursive_edit_1 ();

To avoid problems when we play with actual focus, what happens if we
play with the focus-redirection here instead?


        Stefan

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

[martin rudalics]

 > I don't follow.  If the WM does "Raise on focus", surely it will raise
 > the frame no matter how it acquires the focus.  Such focus is here
 > essential for the working of the minibuffer.

It should not deliberately raise a frame that already has focus.

 > Is it not the case that acquiring the focus with Fx_focus_frame would be
 > better than not doing so?

It does not restore the Emacs 26 behavior.  If you look at the reports
for Bug#8856, Bug#11566 or Bug#11939, you might be able to imagine how
much time I spent to get the behavior right for Drew's setup back then.
It's quite sobering to see my efforts from that period get wasted now.

 >> AFAICT the most simple approach appears to restore the Emacs 26
 >> behavior for sessions with separate minibuffer frames.
 >
 > I'm not sure how simple that would be.  Have you a patch to propose?

No.  I think you should trace all 'minibuffer-follows-selected-frame'
related changes and make them pertinent to the value of that variable.
Then people who need the old behavior could get it back by setting that
variable to nil.  It was an unwritten rule of Emacs development that a
new feature that breaks established behavior should be (a) made optional
and (b) by default turned off.  Maybe that rule doesn't apply any more
but at least (a) should be still supported.

 >> What would the semantics of 'minibuffer-follows-selected-frame' be for
 >> such a session anyway?
 >
 > I've a vague memory of checking this was OK at the time of the change.
 > I can't remember many of the details now, though.

Then please try to remember.  AFAICT 'minibuffer-follows-selected-frame'
should never impact the behavior of separate minibuffer frames.

martin

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

[Alan Mackenzie]

Hello, Martin.

On Fri, Jul 08, 2022 at 09:01:43 +0200, martin rudalics wrote:
>  > I don't follow.  If the WM does "Raise on focus", surely it will
>  > raise the frame no matter how it acquires the focus.  Such focus is
>  > here essential for the working of the minibuffer.

> It should not deliberately raise a frame that already has focus.

OK.  We could add an extra check for the frame already having the focus.
Is there anything else suboptimal about that proposed fix to emacs-28?

>  > Is it not the case that acquiring the focus with Fx_focus_frame
>  > would be better than not doing so?

> It does not restore the Emacs 26 behavior.  If you look at the reports
> for Bug#8856, Bug#11566 or Bug#11939, you might be able to imagine how
> much time I spent to get the behavior right for Drew's setup back then.
> It's quite sobering to see my efforts from that period get wasted now.

If there are bugs, we fix them.  You're surely not saying that the Emacs
26 behaviour was ideal, are you?  I'll take a look at these bug reports
this evening.

Part of the problem is that this desired behaviour is not formulated
anywhere, and there don't appear to be tests in 'make check' for it.

In the mean time, how well does the change to master work?  It attempts
to fix the cause of (rather than just working around) bug #56305.

>  >> AFAICT the most simple approach appears to restore the Emacs 26
>  >> behavior for sessions with separate minibuffer frames.

>  > I'm not sure how simple that would be.  Have you a patch to propose?

> No.  I think you should trace all 'minibuffer-follows-selected-frame'
> related changes and make them pertinent to the value of that variable.
> Then people who need the old behavior could get it back by setting that
> variable to nil.

That would be an enormous amount of work, since the code was to a
significant extent in a chaotic state when I made those changes.  I think
it is now in a less chaotic state.  We surely do not wish to restore the
chaos.

Even If I were to do that, I doubt Eli would accept the result for Emacs
28.2, since it would be too large a change.

Again, how well does my change made last night to master fix the bug?

As a matter of interest, the setting of minibuffer-follows-selected-frame
which gives behaviour closest to the old is non-nil, non-t (e.g. the
symbole `hybrid').

> It was an unwritten rule of Emacs development that a new feature that
> breaks established behavior should be (a) made optional and (b) by
> default turned off.  Maybe that rule doesn't apply any more but at
> least (a) should be still supported.

>  >> What would the semantics of 'minibuffer-follows-selected-frame' be for
>  >> such a session anyway?

>  > I've a vague memory of checking this was OK at the time of the change.
>  > I can't remember many of the details now, though.

> Then please try to remember.  AFAICT 'minibuffer-follows-selected-frame'
> should never impact the behavior of separate minibuffer frames.

Again, bug #56305 was not caused by the m-f-s-f changes, but by some
chaotic code in do_switch_frame which is hopefully now fixed (in master).

I don't agree with you that reverting the minibuffer-follows-select-frame
changes is a good way to fix the current bug, or any similar bugs.

If my last night's commit to master is satisfactory, perhaps it might
somehow be possibly to cherry-pick it into Emacs 28.2.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 8 Jul 2022 10:55:07 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>   56305@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > It does not restore the Emacs 26 behavior.  If you look at the reports
> > for Bug#8856, Bug#11566 or Bug#11939, you might be able to imagine how
> > much time I spent to get the behavior right for Drew's setup back then.
> > It's quite sobering to see my efforts from that period get wasted now.
> 
> If there are bugs, we fix them.  You're surely not saying that the Emacs
> 26 behaviour was ideal, are you?  I'll take a look at these bug reports
> this evening.
> 
> Part of the problem is that this desired behaviour is not formulated
> anywhere, and there don't appear to be tests in 'make check' for it.

Feel free to add commentary that describes the desired behavior in
specific situations.

I don't think how we can have tests for this in the test suite, since
you cannot test this in a batch session.  We could have tests in
test/manual/, though.

> If my last night's commit to master is satisfactory, perhaps it might
> somehow be possibly to cherry-pick it into Emacs 28.2.

I doubt that, as the change is significant and we won't be able to
know if it's right until some time.  It would be wrong to delay Emacs
28.2 until then, IMO, since the situations in which this happens are
somewhat rare and the problems aren't catastrophic.

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

[Alan Mackenzie]

Hello again, Martin.

On Fri, Jul 08, 2022 at 10:55:07 +0000, Alan Mackenzie wrote:
> On Fri, Jul 08, 2022 at 09:01:43 +0200, martin rudalics wrote:
> >  > I don't follow.  If the WM does "Raise on focus", surely it will
> >  > raise the frame no matter how it acquires the focus.  Such focus is
> >  > here essential for the working of the minibuffer.

> > It should not deliberately raise a frame that already has focus.

> OK.  We could add an extra check for the frame already having the focus.
> Is there anything else suboptimal about that proposed fix to emacs-28?

> >  > Is it not the case that acquiring the focus with Fx_focus_frame
> >  > would be better than not doing so?

> > It does not restore the Emacs 26 behavior.

How, precisely, does the behaviour in my proposed patch differ from that
of Emacs 26?

> > If you look at the reports for Bug#8856, Bug#11566 or Bug#11939, you
> > might be able to imagine how much time I spent to get the behavior
> > right for Drew's setup back then.  It's quite sobering to see my
> > efforts from that period get wasted now.

What do you mean by "wasted"?  What fails to work now which worked
immediately after your fixes for these three bugs?

> .... I'll take a look at these bug reports this evening.

I've had a look at those bugs, now, albeit briefly.  They do not contain
concise recipes for reproducing the bugs, and anyway, I don't have a
Windows system to try things out on.  They are bugs where the focus
ended up on the wrong frame, and it was hypothesised that this may have
been because of Windows always giving the focus to newly created frames.

[ .... ]

> > martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Stefan.

On Thu, Jul 07, 2022 at 14:57:02 -0400, Stefan Monnier wrote:
> > diff --git a/src/minibuf.c b/src/minibuf.c
> > index 0fc7f2caa1..71fd62cede 100644
> > --- a/src/minibuf.c
> > +++ b/src/minibuf.c
> > @@ -896,6 +896,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
> >    /* Don't allow the user to undo past this point.  */
> >    bset_undo_list (current_buffer, Qnil);
> >  
> > +  /* If some Emacs frame currently has the window-system focus, give
> > +     it to the minibuffer frame.  This is sometimes needed for
> > +     minibuffer-only frames.  */
> > +  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame)
> > +    Fx_focus_frame (mini_frame, Qt);
> > +
> >    recursive_edit_1 ();

> To avoid problems when we play with actual focus, what happens if we
> play with the focus-redirection here instead?

Ouch!

Well, the Fx_focus_frame is there to cause the window manager's notion
of focus to be set to our frame.  I wouldn't think it would make much
difference whether that's Emacs's "focus-frame" or its "redirected
focus-frame".  The same frame would get the WM-focus.

Whether it would make any difference to the subsequent Emacs frame
management, I couldn't say at the moment.  (My head is spinning from the
last few days' thinking about this.)

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Gregory Heytings]

>
> the code was to a significant extent in a chaotic state when I made 
> those changes.
>

Chaos is in the eyes of the beholder.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> To avoid problems when we play with actual focus, what happens if we
>> play with the focus-redirection here instead?
[...]
> Whether it would make any difference to the subsequent Emacs frame
> management, I couldn't say at the moment.  (My head is spinning from the
> last few days' thinking about this.)

That's why I ask you: last time I looked at the focus-redirection code
I also had trouble, but since you're already deep into it, I figured
I could save myself the trouble ;-)


        Stefan

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

[martin rudalics]

 >> It should not deliberately raise a frame that already has focus.
 >
 > OK.  We could add an extra check for the frame already having the focus.
 > Is there anything else suboptimal about that proposed fix to emacs-28?

If by "extra check" you mean

diff --git a/src/minibuf.c b/src/minibuf.c
index 0fc7f2caa1..71fd62cede 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -896,6 +896,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
    /* Don't allow the user to undo past this point.  */
    bset_undo_list (current_buffer, Qnil);

+  /* If some Emacs frame currently has the window-system focus, give
+     it to the minibuffer frame.  This is sometimes needed for
+     minibuffer-only frames.  */
+  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame)
+    Fx_focus_frame (mini_frame, Qt);
+
    recursive_edit_1 ();

    /* If cursor is on the minibuffer line,

then it does not improve anything here - the minibuffer frame is first
lowered and then raised above the normal frame.  I do not understand the
idea here anyway.  Why give focus to a frame that already has focus?
Why does the comment say "some Emacs frame" while the code checks only
the minibuffer frame?

Recalling my personal experience: I used 'x-focus-frame' in one special
case only - in 'handle-select-window' when 'focus-follows-mouse' is
non-nil.  All other calls are via 'select-frame-set-input-focus' where
the intention to _also_ raise the frame is obvious.  I would never have
called 'x-focus-frame' from C with the default settings - every second
window manager out there will handle it differently.

 > In the mean time, how well does the change to master work?  It attempts
 > to fix the cause of (rather than just working around) bug #56305.

The change to master fixes the bug here.

martin

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

[martin rudalics]

 >>> It does not restore the Emacs 26 behavior.
 >
 > How, precisely, does the behaviour in my proposed patch differ from that
 > of Emacs 26?

In all patches you proposed for the release version the difference is
that with Emacs 26 the normal frame is on top of the minibuffer frame
when the question is asked while with your patches the minibuffer frame
obscures the normal frame.  The minibuffer frame has input focus in
either case.

 >>> If you look at the reports for Bug#8856, Bug#11566 or Bug#11939, you
 >>> might be able to imagine how much time I spent to get the behavior
 >>> right for Drew's setup back then.  It's quite sobering to see my
 >>> efforts from that period get wasted now.
 >
 > What do you mean by "wasted"?  What fails to work now which worked
 > immediately after your fixes for these three bugs?

I neither recall what did not work nor whether I fixed anything at all
nor what got fixed.  I only recall that everything I tried in this area
was extremely fragile and bound to fail immediately when a sequence of
events was disturbed by external intervention.

 >> .... I'll take a look at these bug reports this evening.
 >
 > I've had a look at those bugs, now, albeit briefly.  They do not contain
 > concise recipes for reproducing the bugs, and anyway, I don't have a
 > Windows system to try things out on.  They are bugs where the focus
 > ended up on the wrong frame, and it was hypothesised that this may have
 > been because of Windows always giving the focus to newly created frames.

Such behavior is quite normal on non-Windows systems too.

martin

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

[Alan Mackenzie]

Hello, Martin.

On Sat, Jul 09, 2022 at 10:35:50 +0200, martin rudalics wrote:
>  >> It should not deliberately raise a frame that already has focus.

>  > OK.  We could add an extra check for the frame already having the focus.
>  > Is there anything else suboptimal about that proposed fix to emacs-28?

> If by "extra check" you mean

> diff --git a/src/minibuf.c b/src/minibuf.c
> index 0fc7f2caa1..71fd62cede 100644
> --- a/src/minibuf.c
> +++ b/src/minibuf.c
> @@ -896,6 +896,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>     /* Don't allow the user to undo past this point.  */
>     bset_undo_list (current_buffer, Qnil);

> +  /* If some Emacs frame currently has the window-system focus, give
> +     it to the minibuffer frame.  This is sometimes needed for
> +     minibuffer-only frames.  */
> +  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame)
> +    Fx_focus_frame (mini_frame, Qt);
> +
>     recursive_edit_1 ();

>     /* If cursor is on the minibuffer line,

No, that's not quite what I meant.

> then it does not improve anything here - the minibuffer frame is first
> lowered and then raised above the normal frame.  I do not understand the
> idea here anyway.  Why give focus to a frame that already has focus?
> Why does the comment say "some Emacs frame" while the code checks only
> the minibuffer frame?

The intention was that FRAME_DISPLAY_INFO (XFRAME (mini_frame)) should
get the display structure which contains mini_frame, and that
->x_focus_frame should either be the Emacs frame which has the focus, or
null if some other program currently has the focus.  Only if an Emacs
frame currently has the focus should we refocus onto the minibuffer
frame.

Adding the check whether the minibuffer frame already has the focus,
which I've tried, gives this:



diff --git a/src/minibuf.c b/src/minibuf.c
index 0fc7f2caa1..0d80b2ec90 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -896,6 +896,16 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Don't allow the user to undo past this point.  */
   bset_undo_list (current_buffer, Qnil);
 
+  /* If some Emacs frame currently has the window-system focus, give
+     it to the minibuffer frame.  This is sometimes needed for
+     minibuffer-only frames.  Don't give that frame the focus if it's
+     already got it, since this might cause the frame to be wrongly
+     raised.  */
+  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame
+      && (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame
+	  != XFRAME (mini_frame)))
+    Fx_focus_frame (mini_frame, Qt);
+
   recursive_edit_1 ();
 
   /* If cursor is on the minibuffer line,

How do you react to this suggestion?  Anyhow, I just tried it on a Linux
tty, and it segfaults.  ;-(  So it clearly needs some refinement.


> Recalling my personal experience: I used 'x-focus-frame' in one special
> case only - in 'handle-select-window' when 'focus-follows-mouse' is
> non-nil.  All other calls are via 'select-frame-set-input-focus' where
> the intention to _also_ raise the frame is obvious.

I suggested using s-f-s-input-focus at one time, but you pointed out
that this would raise the frame, which isn't wanted.

> I would never have called 'x-focus-frame' from C with the default
> settings - every second window manager out there will handle it
> differently.

But surely every window manager will give the minibuffer frame the
focus, precisely what we need here?  What could happen with a strange WM
that could be disturbing?

>  > In the mean time, how well does the change to master work?  It attempts
>  > to fix the cause of (rather than just working around) bug #56305.

> The change to master fixes the bug here.

Thanks!

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

 > diff --git a/src/minibuf.c b/src/minibuf.c
 > index 0fc7f2caa1..0d80b2ec90 100644
 > --- a/src/minibuf.c
 > +++ b/src/minibuf.c
 > @@ -896,6 +896,16 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
 >     /* Don't allow the user to undo past this point.  */
 >     bset_undo_list (current_buffer, Qnil);
 >
 > +  /* If some Emacs frame currently has the window-system focus, give
 > +     it to the minibuffer frame.  This is sometimes needed for
 > +     minibuffer-only frames.  Don't give that frame the focus if it's
 > +     already got it, since this might cause the frame to be wrongly
 > +     raised.  */
 > +  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame
 > +      && (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame
 > +	  != XFRAME (mini_frame)))
 > +    Fx_focus_frame (mini_frame, Qt);
 > +
 >     recursive_edit_1 ();
 >
 >     /* If cursor is on the minibuffer line,
 >
 > How do you react to this suggestion?  Anyhow, I just tried it on a Linux
 > tty, and it segfaults.  ;-(  So it clearly needs some refinement.

This doesn't improve anything here.  On Debian I'm using a setup which
is described under "Focus Settings" here

https://docs.xfce.org/xfce/xfwm4/4.12/preferences

In particular, I (a) Automatically raise windows when they receive focus
and I use a (b) Delay before raising focused window.  (a) is for me
indispensable to bring a window to foreground with the mouse (mainly due
to a habit developed while working under Windows where clicking into a
lowered frame to raise it inevitably moved point in the Emacs window
clicked at).  (b) is indispensable to avoid that some arbitrary window
gets raised when moving the mouse over it while trying to reach some
specific window (this is one case mutter handles decidedly better than
xfwm).  If anybody can suggest a better setup for emulating what Emacs
calls 'mouse-autoselect-window' on the display level, I'll be all ears.

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

Fselect_window (old_window, Qt)

call in unwind_format_mode_line (the one you mentioned earlier in this
thread) kicks in causing the window manager to move focus to the normal
frame.  Finally, your patch will ask the window manager to focus the
minibuffer frame again and raise it.

I used the term "apparently" because there are too many do_switch_frame
calls triggered by redisplay in order to attribute them orderly to their
precise origin.  And tracing focus transitions with GDB is next to
impossible because you continuously have to shift focus between GDB and
the debugged application.

Nota bene: In each redisplay cycle, Emacs may ask the window manager at
least twice for each of its frames to refocus it in order to format that
frame's title.  Doesn't a window manager have better things to do than
cater for how applications try to format their internal data?  Doesn't
such an interaction strike anyone as provocative at least?

 > I suggested using s-f-s-input-focus at one time, but you pointed out
 > that this would raise the frame, which isn't wanted.

s-f-s-input-focus would add insult to injury - guaranteeing an unwanted
raise even if 'x-focus-frame' alone would not raise it.

 > But surely every window manager will give the minibuffer frame the
 > focus, precisely what we need here?

I wouldn't even bet on that.  Certainly not with newer generations of
window managers.  A WM may concede input focus upon an application's
request for special windows like dialog boxes only.  We're just lucky if
it allows to give focus to some "normal" window too.

 > What could happen with a strange WM
 > that could be disturbing?

Isn't that the wrong question?  Here we talk about a strange application
that within milliseconds asks the WM to move focus away from one of its
windows and then move it back to the original window in order to format
its internal data.

 >> The change to master fixes the bug here.
 >
 > Thanks!

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.  It doesn't even tell me that there is no other window to
select.  So this cure is certainly worse than the disease.

martin

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

[Alan Mackenzie]

Hello, Martin.

On Sun, Jul 10, 2022 at 10:07:28 +0200, martin rudalics wrote:
>  > diff --git a/src/minibuf.c b/src/minibuf.c
>  > index 0fc7f2caa1..0d80b2ec90 100644
>  > --- a/src/minibuf.c
>  > +++ b/src/minibuf.c
>  > @@ -896,6 +896,16 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>  >     /* Don't allow the user to undo past this point.  */
>  >     bset_undo_list (current_buffer, Qnil);

>  > +  /* If some Emacs frame currently has the window-system focus, give
>  > +     it to the minibuffer frame.  This is sometimes needed for
>  > +     minibuffer-only frames.  Don't give that frame the focus if it's
>  > +     already got it, since this might cause the frame to be wrongly
>  > +     raised.  */
>  > +  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame
>  > +      && (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame
>  > +	  != XFRAME (mini_frame)))
>  > +    Fx_focus_frame (mini_frame, Qt);
>  > +
>  >     recursive_edit_1 ();

>  >     /* If cursor is on the minibuffer line,

>  > How do you react to this suggestion?  Anyhow, I just tried it on a Linux
>  > tty, and it segfaults.  ;-(  So it clearly needs some refinement.

> This doesn't improve anything here.  On Debian I'm using a setup which
> is described under "Focus Settings" here

> https://docs.xfce.org/xfce/xfwm4/4.12/preferences

Thanks!  I use xfce, too.  But I haven't changed anything here away from
its default.  I run Emacs on a tty anyway.

> In particular, I (a) Automatically raise windows when they receive focus
> and I use a (b) Delay before raising focused window.  (a) is for me
> indispensable to bring a window to foreground with the mouse (mainly due
> to a habit developed while working under Windows where clicking into a
> lowered frame to raise it inevitably moved point in the Emacs window
> clicked at).  (b) is indispensable to avoid that some arbitrary window
> gets raised when moving the mouse over it while trying to reach some
> specific window (this is one case mutter handles decidedly better than
> xfwm).  If anybody can suggest a better setup for emulating what Emacs
> calls 'mouse-autoselect-window' on the display level, I'll be all ears.

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

> Then apparently the

> Fselect_window (old_window, Qt)

> call in unwind_format_mode_line (the one you mentioned earlier in this
> thread) kicks in causing the window manager to move focus to the normal
> frame.

(See below.)

> Finally, your patch will ask the window manager to focus the
> minibuffer frame again and raise it.

> I used the term "apparently" because there are too many do_switch_frame
> calls triggered by redisplay in order to attribute them orderly to their
> precise origin.  And tracing focus transitions with GDB is next to
> impossible because you continuously have to shift focus between GDB and
> the debugged application.

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.

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.

> Nota bene: In each redisplay cycle, Emacs may ask the window manager at
> least twice for each of its frames to refocus it in order to format that
> frame's title.  Doesn't a window manager have better things to do than
> cater for how applications try to format their internal data?  Doesn't
> such an interaction strike anyone as provocative at least?

select-window and select-frame should NOT move the 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.

A worthwhile project would be rigourously to determine where the focus
gets changed as a side effect of other things and to remove such side
effects.  Then we could add code to move the focus when we actually want
to.

>  > I suggested using s-f-s-input-focus at one time, but you pointed out
>  > that this would raise the frame, which isn't wanted.

> s-f-s-input-focus would add insult to injury - guaranteeing an unwanted
> raise even if 'x-focus-frame' alone would not raise it.

>  > But surely every window manager will give the minibuffer frame the
>  > focus, precisely what we need here?

> I wouldn't even bet on that.  Certainly not with newer generations of
> window managers.  A WM may concede input focus upon an application's
> request for special windows like dialog boxes only.  We're just lucky if
> it allows to give focus to some "normal" window too.

You're implying that C-x 5 o might not work with such WMs.  That would
not be good.

>  > What could happen with a strange WM
>  > that could be disturbing?

> Isn't that the wrong question?  Here we talk about a strange application
> that within milliseconds asks the WM to move focus away from one of its
> windows and then move it back to the original window in order to format
> its internal data.

As I said, I don't think select-frame/window should move the focus.
Maybe somebody could fix this for Emacs 29.

>  >> The change to master fixes the bug here.

>  > Thanks!

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

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

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sun, 10 Jul 2022 11:34:50 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>   56305@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> 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.

It is hard for me to make a decision about that patch, since it isn't
clear what are its disadvantages.  Martin seems to say that it doesn't
work well?

So can you tell what problem it fixes and what, if any, problems it
causes?

Or maybe we should wait for at least the master to have a complete
fix, and decide then?

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

[Alan Mackenzie]

Hello, Eli.

On Sun, Jul 10, 2022 at 14:47:31 +0300, Eli Zaretskii wrote:
> > Date: Sun, 10 Jul 2022 11:34:50 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
> >   56305@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

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

> It is hard for me to make a decision about that patch, since it isn't
> clear what are its disadvantages.  Martin seems to say that it doesn't
> work well?

Martin's not very happy about things, but I'm not sure what can be
improved quickly.

> So can you tell what problem it fixes ....

In the bug scenario, after C-x C-c, the focus was not on the minibuffer
frame.  Now it is.

> .... and what, if any, problems it causes?

I'm not really aware of any specific problems, but I think Martin might
be.  I see the main problem with the patch is it hasn't been tested on
anything but GNU/Linux and X.  In particular, it hasn't been tested on a
Windows machine or a Mac, at least that I'm aware of.

> Or maybe we should wait for at least the master to have a complete
> fix, and decide then?

You mean, postpone the next Emacs 28 pretest until we've got a better
understanding?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sun, 10 Jul 2022 12:41:23 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org,
>   acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > It is hard for me to make a decision about that patch, since it isn't
> > clear what are its disadvantages.  Martin seems to say that it doesn't
> > work well?
> 
> Martin's not very happy about things, but I'm not sure what can be
> improved quickly.
> 
> > So can you tell what problem it fixes ....
> 
> In the bug scenario, after C-x C-c, the focus was not on the minibuffer
> frame.  Now it is.
> 
> > .... and what, if any, problems it causes?
> 
> I'm not really aware of any specific problems, but I think Martin might
> be.  I see the main problem with the patch is it hasn't been tested on
> anything but GNU/Linux and X.  In particular, it hasn't been tested on a
> Windows machine or a Mac, at least that I'm aware of.

I'll wait to hear from Martin.

> > Or maybe we should wait for at least the master to have a complete
> > fix, and decide then?
> 
> You mean, postpone the next Emacs 28 pretest until we've got a better
> understanding?

No, leave things on the release branch as they are now until then.

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

[Drew Adams]

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

[Big caveat: I'm not following this thread.]

FTR/FWIW -

I expect that there's lots in here that I don't
agree with.

But there's also lots that's happened over the
last few releases that I don't agree with, wrt
Emacs grabbing or changing the focus (frame)
from what my code or user actions have decided.

I tend to think that such changes have been
essentially gratuitous (unconsciously so), even
if someone thought they were called for to fix
this or that reported problem.  Fixing one user
problem can easily mess up other things.  And
fiddling with frame focus is a particularly
sensitive kind of fiddling - including because
different platforms can do things differently.
____


I'll just say this wrt `yes-or-no-p' - at
least wrt how it _used_ to behave.

`yes-or-no-p' is just a function that reads
minibuffer input.  As far as that reading's
concerned, it's "modal" in this sense _only_:
you can't end the reading of minibuffer input
without hitting `C-g' or `C-]' or similar, or
else entering `yes' or `no'.  That's it -
nothing more modal than that.

There's _nothing_ that prevents a user (and
code invoked by the user hitting a key etc.)
from changing the focus to another window or
frame, and carrying out any number of actions
there.  Even multiple frames, successively.
(Not to mention recursive minibuffers.)

There should be _ZERO_ expectation by Emacs
that focus should remain with the minibuffer
during `yes-or-no-p', any more than during
any other minibuffer interaction.

[`y-or-n-p' _has_ been thoroughly modal in
the past.  It expressly did _not_ use the
minibuffer.  But now it reads input from
the minibuffer...]

Users and code need to be in control, able
to change focus away from the minibuffer
and back to it.  Emacs really shouldn't get
in the way.

Once Someone(TM) gets the idea that focus
needs to be kept in the minibuffer, we're
headed down the road to knee-capping code
and user - crippling the minibuffer.

And that, no doubt from good intentions.
Good intentions, but maybe some ignorance
of minibuffer possibilities.

The minibuffer is just a buffer - there's
_NO_ prescribed, ineluctable, "consistent",
simple behavior that can be counted on.

And there should be none.  That's a GOOD
THING.

At least that was the case before any
sanitizing mission started blasting away.

More and more, it seems, if you write code
that takes advantage of how Emacs behaves
you'll lose, because Someone will climb
under the pavement and make a fundamental
change that "fixes" some perceived problem,
upsetting the apple cart above.
____


Here's the general problem I see wrt someone
trying to "regularize", make "consistent",
"simplify" - or whatever - minibuffer
interaction, including focus:

You'll undoubtedly screw things up by making
simplistic assumptions - either about user
or programmatic behavior or about state at
some point.  Sorry to say that (really), but
that's my conclusion.  I know that people
mean well, but that's what happens, IMO.

Why do I say that?  Because I think that's
what's happened, to break my code.

Starting with Emacs 26 (I think Stefan has
pointed to this) - and definitely with Emacs
27, Emacs has apparently tried to get too
smart about such focus things - making more
assumptions about what users and code will
or should do.

The result: _Emacs changes the focus when
it shouldn't_.

I can't be more precise than that.  I've
given up.  I don't have the time to chase
it.  I use only Emacs 26 and earlier now.

My code, including as a result of user
actions, _explicitly_ uses things such as
`select-frame-set-input-focus'.  IOW, my
code, and users, control the UI, including
focus.

Alas, that careful control has been broken
by Emacs.  No doubt Someone thought he was
doing Emacs and its users a favor "cleaning"
things up and making things more "consistent".
Nothing but good intentions, no doubt.  No
carelessness, I assume.

Instead of giving code & users _more_ control,
to handle frame focus as they see fit, Emacs
has itself apparently tried to take control.
Too smart for its own britches.

The fault is in accidental hubris that can
creep in by not appreciating that Emacs
allows for umpteen _zillion_ different
states and interactions.

It's all too easy to think that every user,
use, use case, and setup (configuration),
and all Emacs code, are more or less similar
to your own use, setup, code etc.

Someone makes a "consistency/cleanup" change,
tries it out with a few (even many) setups,
and considers it a job well done.  Shiny.

Maybe someone else reports, in vague terms,
that Emacs now breaks things.  Without a
clear, simple recipe to show that, Emacs
just goes ahead with the new "improvement".
And on it goes.

What was stable for many years becomes
something different, less flexible, etc.

The minibuffer, in particular, is just a
buffer.  And it can be in its own frame.
Users and code can switch focus to & from
that frame, including during minibuffer
interaction.

And other frames (e.g. a dedicated
*Completions* frame) can have their focus
redirected to the minibuffer frame.  And
such redirection doesn't prevent code or
users from switching the focus to such a
frame, and back again.

In short, it should be possible to do
pretty much _anything_ while the
minibuffer is active.

And that - especially - includes changing
the input focus among different frames.

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

[Alan Mackenzie]

Hello, Drew.

[ Top-posting, because the ideas in your post are a bit spread out. ]

I rather agree with most of what you've said here.

In fact in the later posts here, between Martin and me, we've lamented
the fact that the focus gets switched frivolously between frames.  I've
proposed cleaning things up such that select-frame and select-window
would NOT switch the focus under any circumstances (as is documented in
the Elisp manual).  Perhaps if/when we do implement such a clean-up, you
could come on board as one of the main customers, with test cases and
what-not.

Even then, there are times when the focus _must_ be set, for example
when the frame previously focused gets deleted.

The specific problem with yes-or-no-p in this bug was that the focus did
NOT end up on the minibuffer frame, and this was intolerable for users.
(At least, it was intolerable for Martin R.) I analysed the cause, and
found some code redirecting the focus frivolously, going back to 1992.
I have removed this from master, which appears to solve the bug, at
least more or less.  We still have problems getting a fix suitable (i.e.
non-dangerous) for the 28.2 pretest, and this is still under discussion.

However this bug is purely about where the focus goes when yes-or-no-p
is invoked, namely the minibuffer frame.  There is absolutely no
intention of stopping users moving the focus around while the MB is
active.

-- 
Alan Mackenzie (Nuremberg, Germany).


On Sun, Jul 10, 2022 at 16:13:03 +0000, Drew Adams wrote:
> > I think that might be over-stating things.
> > Most of the time, users are just going to be
> > typing "yes" or "no" here.

> [Big caveat: I'm not following this thread.]

> FTR/FWIW -

> I expect that there's lots in here that I don't
> agree with.

> But there's also lots that's happened over the
> last few releases that I don't agree with, wrt
> Emacs grabbing or changing the focus (frame)
> from what my code or user actions have decided.

> I tend to think that such changes have been
> essentially gratuitous (unconsciously so), even
> if someone thought they were called for to fix
> this or that reported problem.  Fixing one user
> problem can easily mess up other things.  And
> fiddling with frame focus is a particularly
> sensitive kind of fiddling - including because
> different platforms can do things differently.
> ____


> I'll just say this wrt `yes-or-no-p' - at
> least wrt how it _used_ to behave.

> `yes-or-no-p' is just a function that reads
> minibuffer input.  As far as that reading's
> concerned, it's "modal" in this sense _only_:
> you can't end the reading of minibuffer input
> without hitting `C-g' or `C-]' or similar, or
> else entering `yes' or `no'.  That's it -
> nothing more modal than that.

> There's _nothing_ that prevents a user (and
> code invoked by the user hitting a key etc.)
> from changing the focus to another window or
> frame, and carrying out any number of actions
> there.  Even multiple frames, successively.
> (Not to mention recursive minibuffers.)

> There should be _ZERO_ expectation by Emacs
> that focus should remain with the minibuffer
> during `yes-or-no-p', any more than during
> any other minibuffer interaction.

> [`y-or-n-p' _has_ been thoroughly modal in
> the past.  It expressly did _not_ use the
> minibuffer.  But now it reads input from
> the minibuffer...]

> Users and code need to be in control, able
> to change focus away from the minibuffer
> and back to it.  Emacs really shouldn't get
> in the way.

> Once Someone(TM) gets the idea that focus
> needs to be kept in the minibuffer, we're
> headed down the road to knee-capping code
> and user - crippling the minibuffer.

> And that, no doubt from good intentions.
> Good intentions, but maybe some ignorance
> of minibuffer possibilities.

> The minibuffer is just a buffer - there's
> _NO_ prescribed, ineluctable, "consistent",
> simple behavior that can be counted on.

> And there should be none.  That's a GOOD
> THING.

> At least that was the case before any
> sanitizing mission started blasting away.

> More and more, it seems, if you write code
> that takes advantage of how Emacs behaves
> you'll lose, because Someone will climb
> under the pavement and make a fundamental
> change that "fixes" some perceived problem,
> upsetting the apple cart above.
> ____


> Here's the general problem I see wrt someone
> trying to "regularize", make "consistent",
> "simplify" - or whatever - minibuffer
> interaction, including focus:

> You'll undoubtedly screw things up by making
> simplistic assumptions - either about user
> or programmatic behavior or about state at
> some point.  Sorry to say that (really), but
> that's my conclusion.  I know that people
> mean well, but that's what happens, IMO.

> Why do I say that?  Because I think that's
> what's happened, to break my code.

> Starting with Emacs 26 (I think Stefan has
> pointed to this) - and definitely with Emacs
> 27, Emacs has apparently tried to get too
> smart about such focus things - making more
> assumptions about what users and code will
> or should do.

> The result: _Emacs changes the focus when
> it shouldn't_.

> I can't be more precise than that.  I've
> given up.  I don't have the time to chase
> it.  I use only Emacs 26 and earlier now.

> My code, including as a result of user
> actions, _explicitly_ uses things such as
> `select-frame-set-input-focus'.  IOW, my
> code, and users, control the UI, including
> focus.

> Alas, that careful control has been broken
> by Emacs.  No doubt Someone thought he was
> doing Emacs and its users a favor "cleaning"
> things up and making things more "consistent".
> Nothing but good intentions, no doubt.  No
> carelessness, I assume.

> Instead of giving code & users _more_ control,
> to handle frame focus as they see fit, Emacs
> has itself apparently tried to take control.
> Too smart for its own britches.

> The fault is in accidental hubris that can
> creep in by not appreciating that Emacs
> allows for umpteen _zillion_ different
> states and interactions.

> It's all too easy to think that every user,
> use, use case, and setup (configuration),
> and all Emacs code, are more or less similar
> to your own use, setup, code etc.

> Someone makes a "consistency/cleanup" change,
> tries it out with a few (even many) setups,
> and considers it a job well done.  Shiny.

> Maybe someone else reports, in vague terms,
> that Emacs now breaks things.  Without a
> clear, simple recipe to show that, Emacs
> just goes ahead with the new "improvement".
> And on it goes.

> What was stable for many years becomes
> something different, less flexible, etc.

> The minibuffer, in particular, is just a
> buffer.  And it can be in its own frame.
> Users and code can switch focus to & from
> that frame, including during minibuffer
> interaction.

> And other frames (e.g. a dedicated
> *Completions* frame) can have their focus
> redirected to the minibuffer frame.  And
> such redirection doesn't prevent code or
> users from switching the focus to such a
> frame, and back again.

> In short, it should be possible to do
> pretty much _anything_ while the
> minibuffer is active.

> And that - especially - includes changing
> the input focus among different frames.

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

[martin rudalics]

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

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

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

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

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

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

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.

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

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?

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

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

martin

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

[Eli Zaretskii]

> Date: Mon, 11 Jul 2022 09:45:59 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>  56305@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > 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.

Can you tell how inhibit-redisplay is related to the original recipe
in this bug?  Specifically, at what point is inhibit-redisplay set in
that recipe and by which code?

Thanks.

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

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

[Eli Zaretskii]

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

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

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

This sounds problematic at the very least for cases like
`with-selected-window` and `save-window-excursion`, where we don't
really want the code to "set and (un/re)set" the focus.  And similarly
when code does `select-window` while Emacs doesn't have focus at all.

We do have a kind of messy situation w.r.t distinguishing the notion of
selected-frame (and selected-window to some extend) from its interaction
with window-manager focus.  But I'm not sure we can (nor should) really
unify the two.


        Stefan

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

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

I think we need to distinguish the WM-level notion of focus from an
"Emacs-internal" notion of focus.

From that point of view, WM-focus and raising should be changed (from
ELisp) only in fairly rare circumstances.

> OK, so maybe we could agree that select-window ought to move focus onto
> the target frame,

Hmm... maybe in some cases, but probably not when Emacs doesn't have focus.

> but not raise it (modulo fascistic window managers).

Indeed.

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

In theory we do separate them, with things like
select-frame-set-input-focus/x-focus-frame/raise-frame on one side and
select-frame/window on the other.


        Stefan

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

[Alan Mackenzie]

Hello, Stefan.

On Mon, Jul 11, 2022 at 13:06:40 -0400, Stefan Monnier 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"?

> This sounds problematic at the very least for cases like
> `with-selected-window` and `save-window-excursion`, where we don't
> really want the code to "set and (un/re)set" the focus.  And similarly
> when code does `select-window` while Emacs doesn't have focus at all.

Actually, at the moment I don't believe that select-window does grab the
focus.  I've been a bit confused about this over the last day or so.

> We do have a kind of messy situation w.r.t distinguishing the notion of
> selected-frame (and selected-window to some extend) from its interaction
> with window-manager focus.  But I'm not sure we can (nor should) really
> unify the two.

No.  But if we did, it would be via an extra argument `no-focus' to
select-window.  I still say no.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Stefan.

On Mon, Jul 11, 2022 at 13:34:55 -0400, Stefan Monnier wrote:
> > 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?

> I think we need to distinguish the WM-level notion of focus from an
> "Emacs-internal" notion of focus.

> >From that point of view, WM-focus and raising should be changed (from
> ELisp) only in fairly rare circumstances.

Like C-x 5 o, you mean?  ;-)

> > OK, so maybe we could agree that select-window ought to move focus onto
> > the target frame,

Or, on the other hand, maybe not.

> Hmm... maybe in some cases, but probably not when Emacs doesn't have focus.

> > but not raise it (modulo fascistic window managers).

> Indeed.

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

> In theory we do separate them, with things like
> select-frame-set-input-focus/x-focus-frame/raise-frame on one side and
> select-frame/window on the other.

I'm talking more about the practice than the theory.  This bug happened
when a select-frame grabbed the focus for the wrong frame.  select-frame
isn't meant to do that.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

 > Can you tell how inhibit-redisplay is related to the original recipe
 > in this bug?  Specifically, at what point is inhibit-redisplay set in
 > that recipe and by which code?

It's all explained here in gui_consider_frame_title:

       /* select-frame calls resize_mini_window, which could resize the
	 mini-window and by that undo the effect of this redisplay
	 cycle wrt minibuffer and echo-area display.  Binding
	 inhibit-redisplay to t makes the call to resize_mini_window a
	 no-op, thus avoiding the adverse side effects.  */

       /* The following was moved before the record_unwind_protect form
	 below to inhibit redisplay also when restoring the selected
	 window/frame: This avoids that resize_mini_window sizes back
	 the minibuffer window of a temporarily selected frame.  See
	 Bug#34317.  */
       specbind (Qinhibit_redisplay, Qt);

Obviously, gui_consider_frame_title should never even try to resize the
mini window in the first place.  The same holds for moving the frame's
focus.

martin

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

[martin rudalics]

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

This at least explains why you never experience focus problems with your
setup.

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

Thanks.  I will try that.

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

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

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

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

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.

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

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.
Making the minibuffer follow the selected frame was just the final stab.

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

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

martin

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

[Drew Adams]

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

;-)   Well put.

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

Odd.  I have no recollection of ever not being
convinced that frame operations are often beyond
Emacs's control (i.e., that window mgrs rule the
roost), or that `display-buffer' isn't, itself,
about selecting a window.

But likely this is an abstract interpretation on
your part of some concrete discussion about some
concrete problem/bug.  The devil of whatever
disagreement is likely in the details - that's
my guess.

> You're barking at the wrong tree.  That code worked well for half of
> its lifetime.  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.

As I don't follow commits, could you situate the
change you're talking about in terms of a given
Emacs release or past discussion (e.g. bug thread)?
I'm curious about what got broken when (and why).

> 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.
> Making the minibuffer follow the selected frame was just the final
> stab.

Thanks for such history.  I haven't experienced
the fallout from the minibuffer following the
selected frame (I'm stuck in Emacs 26).  But I
appreciate getting your perspective about what's
been going on.

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

Probably easier said than done?

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

[Eli Zaretskii]

> Date: Tue, 12 Jul 2022 09:33:00 +0200
> Cc: acm@muc.de, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Can you tell how inhibit-redisplay is related to the original recipe
>  > in this bug?  Specifically, at what point is inhibit-redisplay set in
>  > that recipe and by which code?
> 
> It's all explained here in gui_consider_frame_title:
> 
>        /* select-frame calls resize_mini_window, which could resize the
> 	 mini-window and by that undo the effect of this redisplay
> 	 cycle wrt minibuffer and echo-area display.  Binding
> 	 inhibit-redisplay to t makes the call to resize_mini_window a
> 	 no-op, thus avoiding the adverse side effects.  */
> 
>        /* The following was moved before the record_unwind_protect form
> 	 below to inhibit redisplay also when restoring the selected
> 	 window/frame: This avoids that resize_mini_window sizes back
> 	 the minibuffer window of a temporarily selected frame.  See
> 	 Bug#34317.  */
>        specbind (Qinhibit_redisplay, Qt);

OK, but then we should have a comment pointing to this in the change
you proposed for emacs-28, and I agree to fix the problem as you
suggested with that comment added.

Thanks.

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

[martin rudalics]

 >> 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.
 >
 > Odd.  I have no recollection of ever not being
 > convinced that frame operations are often beyond
 > Emacs's control (i.e., that window mgrs rule the
 > roost), or that `display-buffer' isn't, itself,
 > about selecting a window.

Then how about

   This is driving me crazy. I've tried a zillion ways to try to work around
   this problem, to no avail.

   On MS Windows, whenever a new frame is created, it becomes
   "selected"/"focussed". I use quote-marks here, because I think it might be
   more than what Emacs calls frame selection & focus. I admit that it's
   unclear to me just what's going on.

   ...

   I've tried every hack I can think of, from saving and restoring the selected
   buffer/window/frame, to redirecting and un-redirecting the frame focus, to
   playing with before-make-frame-hook and after-make-frame-functions. I cannot
   get the new frame to become un-"selected"/"focussed" and let me continue to
   use the minibuffer for input.

 > As I don't follow commits, could you situate the
 > change you're talking about in terms of a given
 > Emacs release or past discussion (e.g. bug thread)?
 > I'm curious about what got broken when (and why).

The original commit from 2008 can be studied here:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6355802033d202c63f6fff4b77bf2b0c7aecceef

It was complemented in 2012 by:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c6bf30222430f41fbb696e296f0f63f465eefc35

I have not tried to find out which one is responsible for the current
behavior nor which release first showed it.  The oldest version I can
build here is Emacs 24.  Neither of these commits hints at a prior bug
or discussion explaining why they were considered necessary.

It's interesting that these commits, while mostly acting on the function
unwind_format_mode_line, do not affect the formatting of mode lines via
display_mode_lines because the part of the vector used by these commits
is always NULL, nil or false there.  Hence the later check

   if (WINDOW_LIVE_P (old_window))

always fails when called from display_mode_line and display_mode_lines
correctly restores old window and frame via restore_selected_window.

Restoring the current buffer could be the only worthy contribution of
these changes but ironically is not done from display_mode_line - the
second argument of format_mode_line_unwind_data being NULL there.

 >> We should eliminate the original sin and be
 >> done with it once and for all.
 >
 > Probably easier said than done?

It's trivial because display_mode_lines handles it correctly.  The only
difficulty is to convince people that the commits mentioned above are
fundamentally flawed.  So far, my explanations have been met with cold
disregard.

martin

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> You're barking at the wrong tree.  That code worked well for half of its
> lifetime.  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.

In case you intend to fix this apparent blunder of mine: the point of
that commit was to set the selected window and frame so that ELisp code
run from the `mode-line-format` would see meaningful and consistent
values of selected-frame/window (and companions like the
frame-selected-window of the selected-frame, ...).

If calling `Fselect_window` with a non-nil `norecord` argument messes
things up somehow then maybe we should fix `Fselect_window` accordingly,
or otherwise provide a "more bare bones" function that DTRT.

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.

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

I can't see the connection between these bugs at the above commit, sorry.


        Stefan

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

[Alan Mackenzie]

Hello, Stefan.

On Sat, Jul 16, 2022 at 19:39:10 -0400, Stefan Monnier wrote:
> > You're barking at the wrong tree.  That code worked well for half of its
> > lifetime.  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.

> In case you intend to fix this apparent blunder of mine: the point of
> that commit was to set the selected window and frame so that ELisp code
> run from the `mode-line-format` would see meaningful and consistent
> values of selected-frame/window (and companions like the
> frame-selected-window of the selected-frame, ...).

Yes, like I guessed in my post yesterday in this thread.

> If calling `Fselect_window` with a non-nil `norecord` argument messes
> things up somehow then maybe we should fix `Fselect_window` accordingly,
> or otherwise provide a "more bare bones" function that DTRT.

I would be in favour of the "more bare bones" function.  Fselect_window
is pretty much a command, and does far too much (including sometimes
shifting the focus) for an internal low-level function.  It's doc string
is incomplete in this regard, and its entry in the Elisp manual is vague
and shifty.

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.

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

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

> I can't see the connection between these bugs at the above commit, sorry.

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.

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.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

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.

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

> 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 :-)


        Stefan

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

[Alan Mackenzie]

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

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

[martin rudalics]

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

The doc-string of 'focus-follows-mouse' says:

   You should set this variable to tell Emacs how your window manager
   handles focus, since there is no way in general for Emacs to find out
   automatically.

So do you mean to add similar options that allows users to tell Emacs
how their window manager is supposed to behave wrt foucs handling, frame
raising and the like?  I suspect most users have no idea how their WM
behaves in these regards.  In either case this would be only tangential
to the current issue.

 > Again, where are our capability variables?

Maybe someone can tell us.

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

'next-window' tries to handle every possible use case instead of DTRT in
the few practical cases.  But that ship sailed a long time ago and now
we can only try to keep the old behavior in place as faithfully as
possible because there are too many callers out there that might depend
on its once established functionality.

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

do_switch_frame was Fhandle_switch_frame which was Fselect_frame.  Once
Fselect_frame itself accepted 'switch-frame' events (that's where the
"if (CONSP (frame)" part comes from) and asked for redirecting frame
focus.  Later Fhandle_switch_frame was invented to handle requests
coming from Fselect_frame, Fdelete_frame and switch-frame events.  Then
do_switch_frame was invented and Fhandle_switch_frame became a wrapper
for that.  In 2001 the code for resizing the minibuffer window was added
to do_switch_frame.  In a nutshell, all these additional functions were
provided to better sort out two underlying behaviors:

(1) The WM tells us that it now will direct input to another frame and
     Emacs must select that frame in order to stay in synch with the WM.

(2) Emacs wants to change the selected frame and we have to inform the
     WM about that change so it will direct input to it and call us back
     via (1) that it now will do so.

Be it as it may, the history sketched above should tell C coders to
refrain from calling anything that could end up in any of the functions
mentioned above plus Fselect_window which ends up calling Fselect_frame
when the argument window is on another frame.  These functions may do
lots of things other than resizing minibuffer windows and redirecting
frame focus.  Why on earth should title bar formatting do any of the
following:

- set f->select_mini_window_flag

- mark the window for redisplay or ask to redisplay_other_windows

- call bset_last_selected_window

- call move_minibuffers_onto_frame

- set last_nonminibuf_frame

- set internal_last_event_frame

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

If that were the case, then mode line formatting should have called
Fselect_window long ago.  But Gerd's code from 2001 which "just sets the
variables" is still around and handles that case without larger
complaints ever since.  We fixed the case where a frame's selected
window was not in synch and one where a window got deleted by the mode
line formatting code in between.

 > I don't recall seeing
 > any comments about Fselect_window saying "be careful!".

I'd always try to "be careful" when calling a primitive function from C.

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

Irony of sorts?  The patch I proposed was categorically refused.

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

Setting 'minibuffer-follows-selected-frame' to nil doesn't prevent the
bug from happening here.

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

Because we had that in Emacs 28.1 and you reverted it for Emacs 28.2.

martin

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

[martin rudalics]

 > In case you intend to fix this apparent blunder of mine: the point of
 > that commit was to set the selected window and frame so that ELisp code
 > run from the `mode-line-format` would see meaningful and consistent
 > values of selected-frame/window (and companions like the
 > frame-selected-window of the selected-frame, ...).

How are display_mode_line or display_mode_lines affected by that commit?

As an aside: 'mode-line-format' claims that it is a

   Template for displaying mode line for current buffer.

which is misleading at least.  A mode line belongs to a window and
reflects the values used for displaying a buffer in that window.
Whatever consistency we want here is necessitated by the fact that
redisplay has to set up the current buffer appropriately ('window-point'
replacing the buffer's point, for example, so line numbers, percentages
or 'which-func-mode' appear correct).  Elisp code hardly cares.

Worse even: People who want to know, for example, whether the mode line
belongs to the selected window have to use 'old-selected-window' for
getting that.  Whether a window is "really" selected is ultimately
hidden by Kim's face trick for displaying selected/non-selected windows'
mode lines.

And by no means I'd ask for changing this.  But a better explanation in
the doc-strings and the manual should be in order.  End of the aside.

 > If calling `Fselect_window` with a non-nil `norecord` argument messes
 > things up somehow then maybe we should fix `Fselect_window` accordingly,
 > or otherwise provide a "more bare bones" function that DTRT.
 >
 > 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).

NORECORD is not about focus.

 > And neither should it call things like `resize_mini_window`, I think.
 >
 >> 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.
 >
 > I can't see the connection between these bugs at the above commit, sorry.

They are a direct result of x/gui_consider_frame_title calling
Fselect_window calling resize_mini_window and were fixed by binding
'inhibit-redisplay' appropriately in x/gui_consider_frame_title.

martin

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> to do_switch_frame.  In a nutshell, all these additional functions were
> provided to better sort out two underlying behaviors:
>
> (1) The WM tells us that it now will direct input to another frame and
>     Emacs must select that frame in order to stay in synch with the WM.
>
> (2) Emacs wants to change the selected frame and we have to inform the
>     WM about that change so it will direct input to it and call us back
>     via (1) that it now will do so.

And of course we also need (3) Emacs wants to change the selected frame
without touching anything related to focus because it's just a temporary
change to run code in another context.


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> In case you intend to fix this apparent blunder of mine: the point of
>> that commit was to set the selected window and frame so that ELisp code
>> run from the `mode-line-format` would see meaningful and consistent
>> values of selected-frame/window (and companions like the
>> frame-selected-window of the selected-frame, ...).
> How are display_mode_line or display_mode_lines affected by that commit?

I'm sorry, I don't understand the question.

> Worse even: People who want to know, for example, whether the mode line
> belongs to the selected window have to use 'old-selected-window' for
> getting that.

Not sure "worse" than what.

Clearly when computing the mode-line, there are 2 windows of interest:
the one to which this mode-line belongs and the one that's currently
considered (from the outside) as "the selected window".  Only one of the
two can be "the selected window" while computing the mode-line, and in
my experience most code wants/needs this to be the mode-line's window
rather than "the one that's currently considered (from the outside) as
the selected window".

> And by no means I'd ask for changing this.  But a better explanation in
> the doc-strings and the manual should be in order.  End of the aside.

I didn't know that `old-selected-window` could be used for that (when
I installed the patch, there was simply no such option and my
recommendation when people needed such a thing was to use
a `pre-redisplay-hook` to set some global var to remember the window
that was selected when entering redisplay).

>> If calling `Fselect_window` with a non-nil `norecord` argument messes
>> things up somehow then maybe we should fix `Fselect_window` accordingly,
>> or otherwise provide a "more bare bones" function that DTRT.
>>
>> 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).
>
> NORECORD is not about focus.

Then we need something like it but to say "I just want to change
selected-window temporarily, so don't mess with focus or any such thing".

Or maybe, an alternative would be to wait until the next redisplay to
reflect the effect of select-frame/window on focus.

>> I can't see the connection between these bugs at the above commit, sorry.
> They are a direct result of x/gui_consider_frame_title calling
> Fselect_window calling resize_mini_window and were fixed by binding
> 'inhibit-redisplay' appropriately in x/gui_consider_frame_title.

Hmm... following the idea above, maybe select-frame/window should never
call resize_mini_window, and instead that should only take place at the
next redisplay.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Alan Mackenzie <acm@muc.de>,  Eli Zaretskii <eliz@gnu.org>,
>   56305@debbugs.gnu.org
> Date: Mon, 18 Jul 2022 10:58:09 -0400
> 
> Hmm... following the idea above, maybe select-frame/window should never
> call resize_mini_window, and instead that should only take place at the
> next redisplay.

That's exactly what happens: resize_mini_window just fiddles with some
variables, the actual resizing happens as part of redisplay.  It's the
moral equivalent of what happens when the user types "C-x ^".

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Hmm... following the idea above, maybe select-frame/window should never
>> call resize_mini_window, and instead that should only take place at the
>> next redisplay.
>
> That's exactly what happens: resize_mini_window just fiddles with some
> variables, the actual resizing happens as part of redisplay.  It's the
> moral equivalent of what happens when the user types "C-x ^".

But we need to make sure that selecting a window and then "selecting
back" the original doesn't cause those vars to be changed.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rudalics@gmx.at,  acm@muc.de,  56305@debbugs.gnu.org
> Date: Mon, 18 Jul 2022 12:12:34 -0400
> 
> >> Hmm... following the idea above, maybe select-frame/window should never
> >> call resize_mini_window, and instead that should only take place at the
> >> next redisplay.
> >
> > That's exactly what happens: resize_mini_window just fiddles with some
> > variables, the actual resizing happens as part of redisplay.  It's the
> > moral equivalent of what happens when the user types "C-x ^".
> 
> But we need to make sure that selecting a window and then "selecting
> back" the original doesn't cause those vars to be changed.

That shouldn't be hard to arrange (in fact, binding inhibit-redisplay
does precisely that).

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

[martin rudalics]

 > And of course we also need (3) Emacs wants to change the selected frame
 > without touching anything related to focus because it's just a temporary
 > change to run code in another context.

"Of course"?  If I have a window or frame that I usually never want to
become selected, evaluating 'mode-line-format' will mercilessly tell me
that that window or frame is the selected one.

martin

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

[martin rudalics]

 >>> In case you intend to fix this apparent blunder of mine: the point of
 >>> that commit was to set the selected window and frame so that ELisp code
 >>> run from the `mode-line-format` would see meaningful and consistent
 >>> values of selected-frame/window (and companions like the
 >>> frame-selected-window of the selected-frame, ...).
 >> How are display_mode_line or display_mode_lines affected by that commit?
 >
 > I'm sorry, I don't understand the question.

Above you said that "the point of that commit was to set the selected
window and frame so that ELisp code run from the `mode-line-format`
would see meaningful and consistent values ...".  The C functions that
evaluate 'mode-line-format' for redisplay are display_mode_lines and
display_mode_line and those functions did set the selected window and
frame before that commit and continued to do so after your commit in the
same way.  FWICS your commit changed the behavior of formatting frame
titles only.

 >> Worse even: People who want to know, for example, whether the mode line
 >> belongs to the selected window have to use 'old-selected-window' for
 >> getting that.
 >
 > Not sure "worse" than what.

Worse than being "misleading".

 > Clearly when computing the mode-line, there are 2 windows of interest:
 > the one to which this mode-line belongs and the one that's currently
 > considered (from the outside) as "the selected window".  Only one of the
 > two can be "the selected window" while computing the mode-line, and in
 > my experience most code wants/needs this to be the mode-line's window
 > rather than "the one that's currently considered (from the outside) as
 > the selected window".

"The selected window is the window in which the standard cursor for
selected windows appears."  I see no outside POV here.  And once more: I
don't ask to change this design but at least to tell users about it.

 >> NORECORD is not about focus.
 >
 > Then we need something like it but to say "I just want to change
 > selected-window temporarily, so don't mess with focus or any such thing".

Say to whom and where?

martin

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics [2022-07-19 10:09:33] wrote:
>> And of course we also need (3) Emacs wants to change the selected frame
>> without touching anything related to focus because it's just a temporary
>> change to run code in another context.
> "Of course"?  If I have a window or frame that I usually never want to
> become selected, evaluating 'mode-line-format' will mercilessly tell me
> that that window or frame is the selected one.

I don't see any conflict between what I wrote and what you wrote.
The `selected-window` is just like the `current-buffer`: a context
passed around, like a set of default arguments.

The fact that it can also influence focus is not related to the
evaluation of the mode-line-format.


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> >> Hmm... following the idea above, maybe select-frame/window should never
>> >> call resize_mini_window, and instead that should only take place at the
>> >> next redisplay.
>> >
>> > That's exactly what happens: resize_mini_window just fiddles with some
>> > variables, the actual resizing happens as part of redisplay.  It's the
>> > moral equivalent of what happens when the user types "C-x ^".
>> 
>> But we need to make sure that selecting a window and then "selecting
>> back" the original doesn't cause those vars to be changed.
>
> That shouldn't be hard to arrange (in fact, binding inhibit-redisplay
> does precisely that).

But `save-selected-window` can't&shouldn't bind `inhibit-redisplay`.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rudalics@gmx.at,  acm@muc.de,  56305@debbugs.gnu.org
> Date: Tue, 19 Jul 2022 16:48:44 -0400
> 
> >> >> Hmm... following the idea above, maybe select-frame/window should never
> >> >> call resize_mini_window, and instead that should only take place at the
> >> >> next redisplay.
> >> >
> >> > That's exactly what happens: resize_mini_window just fiddles with some
> >> > variables, the actual resizing happens as part of redisplay.  It's the
> >> > moral equivalent of what happens when the user types "C-x ^".
> >> 
> >> But we need to make sure that selecting a window and then "selecting
> >> back" the original doesn't cause those vars to be changed.
> >
> > That shouldn't be hard to arrange (in fact, binding inhibit-redisplay
> > does precisely that).
> 
> But `save-selected-window` can't&shouldn't bind `inhibit-redisplay`.

I don't think I understand.  First, how is save-selected-window
related to this discussion?  And second, why cannot/shouldn't it bind
inhibit-redisplay?

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> But `save-selected-window` can't&shouldn't bind `inhibit-redisplay`.
> I don't think I understand.  First, how is save-selected-window
> related to this discussion?

`save-selected-window` uses `select-window`.
[ Actually I meant to write `with-selected-window` which is even more
  directly related, but the same hold for `save-selected-window`.  ]

> And second, why cannot/shouldn't it bind inhibit-redisplay?

Because code within a `save-selected-window` may want to use `sit-for`,
`read-event`, `recursive-edit`, `read-from-minibuffer`, ..


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rudalics@gmx.at,  acm@muc.de,  56305@debbugs.gnu.org
> Date: Wed, 20 Jul 2022 10:54:46 -0400
> 
> >> But `save-selected-window` can't&shouldn't bind `inhibit-redisplay`.
> > I don't think I understand.  First, how is save-selected-window
> > related to this discussion?
> 
> `save-selected-window` uses `select-window`.

That select-window will do nothing unless BODY changes the selected
window, right?  So it isn't save-selected-window's business to do
anything about the issue at hand: it's the business of that BODY.

> [ Actually I meant to write `with-selected-window` which is even more
>   directly related, but the same hold for `save-selected-window`.  ]

What is the problem with with-selected-window, exactly?

> > And second, why cannot/shouldn't it bind inhibit-redisplay?
> 
> Because code within a `save-selected-window` may want to use `sit-for`,
> `read-event`, `recursive-edit`, `read-from-minibuffer`, ..

You assume the binding should be in effect while BODY runs.  But
that's not needed: you only need to do that around the call to
select-window (if at all).

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> > And second, why cannot/shouldn't it bind inhibit-redisplay?
>> Because code within a `save-selected-window` may want to use `sit-for`,
>> `read-event`, `recursive-edit`, `read-from-minibuffer`, ..
> You assume the binding should be in effect while BODY runs.  But
> that's not needed: you only need to do that around the call to
> select-window (if at all).

Ah, that's better, indeed.

I'd rather make `select-window` take an explicit arg (or a special
value of `norecord`) rather than pass that arg implicitly via
a dynbound variable (especially one like `inhibit-redisplay` whose name
doesn't say clearly what it has to do with `select-window`).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rudalics@gmx.at,  acm@muc.de,  56305@debbugs.gnu.org
> Date: Thu, 21 Jul 2022 11:07:20 -0400
> 
> I'd rather make `select-window` take an explicit arg (or a special
> value of `norecord`) rather than pass that arg implicitly via
> a dynbound variable (especially one like `inhibit-redisplay` whose name
> doesn't say clearly what it has to do with `select-window`).

If this can work, I don't think I would object.  Somehow, I doubt it
will work when the window is on another frame.