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

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

>  > But the point was that the minibuffer buffer was the 
>  > (current-buffer) here, suggesting to me that the minibuffer
>  > frame (and its buffer) was selected.
>  >
>  > Is that TRT?  I didn't think so.  I didn't think that just 
>  > calling `redirect-*' would/should also select the frame and
>  > its buffer.  That is why I said this:
> 
> Just calling `redirect-*' does not select the frame and its 
> buffer.  But `yes-or-no-p' does since otherwise you won't be
> able to type into the minibuffer - here's the relevant piece
> in read_minibuf:
> 
>    /* Display this minibuffer in the proper window.  */
>    Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil);
>    Fselect_window (minibuf_window, Qnil);
>    XWINDOW (minibuf_window)->hscroll = 0;

Well, OK.  But normally, after the input is read the selected window/frame
returns to what it was before the reading.  No?

IOW, yes, it is normal and necessary for yes/no input to be entered in the
minibuffer window, so naturally that window must be selected for the duration of
that user input.

The problem is (apparently) that the minibuffer buffer remains selected after
the reading, i.e., the (current-buffer) is " *Minibuf-0*".  Thus, a subsequent
command such as `C-x k' sees that buffer as the current one.  That has not
happened before - it seems to come as a result of redirecting the frame focus,
but perhaps that is just a catalyst/revealer.