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

[martin rudalics <rudalics@gmx.at>]

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

I don't know.  read_minibuf does (my remarks appear below the code):

   /* Choose the minibuffer window and frame, and take action on them.  */

   choose_minibuf_frame ();

   record_unwind_protect (choose_minibuf_frame_1, Qnil);

I don't understand the last two calls, IMHO one of them seems redundant.

   record_unwind_protect (Fset_window_configuration,
			 Fcurrent_window_configuration (Qnil));

I don't know which frame is selected here in your case.

   /* If the minibuffer window is on a different frame, save that
      frame's configuration too.  */
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
   if (!EQ (mini_frame, selected_frame))
     record_unwind_protect (Fset_window_configuration,
			   Fcurrent_window_configuration (mini_frame));

But this should restore the configuration of your minibuffer frame.  I
don't have the slightest idea whether and how the selected window is
preserved provided it's on another frame.  You could try checking via
`minibuffer-setup-hook' and `minibuffer-exit-hook' but I'm afraid the
latter is executed too early and you're still in the same state of
affairs as in the setup hook.  Are you stuck in the minibuffer window
even when you do `top-level'?

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

If this were the case, we'd have a bug.  But the code doesn't indicate that.

martin