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

["Drew Adams" <drew.adams@oracle.com>]

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

OK.  I really know nothing about this area.

> 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 see.  And if reading from the minibuffer was already started (e.g. before the
new frame was actually created) then the new frame will not have its focus
directed to the minibuffer, even though reading is in progress.

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

OK.