bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics <rudalics@gmx.at>]

 > Now maybe what was really meant is that if X redirects to Y and Y redirects to Z
 > then X ends up redirecting to Z.  That would make sense (and also go without
 > saying).  Dunno.

Maybe because it would be too easy to introduce circular redirection
this way.

 >> Now suppose a minibuffer-only frame is selected and had focus directed to
 >> itself. If now a minibuffer-less frame gets selected, focus will be
 >> directed to that frame which hardly makes sense to me.
 >
 > I agree.  But why would someone redirect the minibuffer frame's focus to itself?

Indeed, that would not be reasonable.

 > What are you envisioning?

I was only speculating.

 >> Someone (maybe Jan) once said that it's hard to override any such
 >> decisions when they are made by the window manager.
 >
 > I did not mean override (prevent/nullify).  I meant automatically take remedial
 > action after the window manager's autofocus takes effect.  I.e., automatically
 > move the focus back where it was.

I'm not quite sure what "after" means in this context.  IIUC Emacs is
not informed that the frame has been posted on screen.  It will know
about it only implicitly when it's passed input directed to that frame.

 >> IIUC creating a WM window (via CreateWindow) returns a handle to a new
 >> WM window independently from whether that window already
 >> appears on the screen and/or obscures other windows.
 >>
 >> I don't know whether and how the window manager informs Emacs
 >> that a window has appeared on the screen.  I suppose it doesn't
 >> and that information is passed to emacs implicitly
 >> when the user "selects" that window by using the keyboard or
 >> the mouse.
 >
 > How does Emacs determine the selected frame?  Doesn't the code of
 > `selected-frame' help understand this?

Emacs selects a new frame.  But if it's minibufferless, it doesn't
necesarily redirect input to the minibuffer frame.  IIUC it does so only
when it reads input from that frame.

 > I did not really mean "redirects the prompt".  I was thinking of it moving the
 > input focus (which would also put the prompt where that focus is, presumably).

I suppose we mean the same here.

 > My guess was/is that it might always move the focus to the minibuffer frame, but
 > that the focus is then moved away from it to the new frame that is popped up.

The window manager moves the focus to the new frame and Emacs selects
it.  But Emacs apparently does not redirect input focus.

 > How do you know that that is not what happens?  I.e., how do you know that there
 > are some situations where the focus is *not* (initially) switched to the
 > minibuffer frame?  (I'm not saying you are wrong - just wondering how you know
 > that.)

I have no other explanation.

 >> From what you said it seems to work as long as no new frames are
 >> created.  When a new frame is created, it may take some time for this
 >> mechanism to adapt itself to the new configuration.
 >
 > Perhaps, but waiting does not help.  Perhaps you meant that there is some
 > timeout and if things are too slow then the focus is automatically moved to the
 > new frame?

My speculation is still the same: The window manager focuses the new
frame and Emacs does not redirect input to the minibuffer frame.

martin