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

[Drew Adams]

> Usually, each frame must have a minibuffer window.  How else should
> `read-minibuffer' work?

It can read from the minibuffer in a standalone minibuffer frame?

> But within the C routines this invariant seems too strong.
> 
>  > But certainly there can be frames that have no minibuffer 
>  > - their `minibuffer' frame parameter value is nil.
> 
> That's a different story.  IIUC only the selected frame must have the
> minibuffer_window slot always set.

That's what I was guessing, that a frame's `minibuffer' parameter might be
non-nil but it somehow has a minibuffer _window_.  Seems odd, but I guess these
things are at two different levels.  I am used to the Lisp & frame level - I
know almost nothing about the C & window level.

>  >> Fredirect_frame_focus (selected_frame, mini_frame); in
>  >> read_minibuf should redirect focus but apparently it doesn't.
>  >
>  > Again, are you sure...?...
> 
> I'm just speculating.  Note, however, that the redirection
> in the code above works only for the selected frame.
> That's why I ask the `yes-or-no-p' questions with the 
> new frame selected.
> 
> Why don't you try what I suggested earlier: Put something on
> `mouse-leave-buffer-hook' and in a `pre-' or
> `post-command-hook' check whether that something got executed.
> Then you can be sure that somewhere in between a
> `handle-switch-frame' interfered.

Sorry, I don't follow you (and I haven't found where you suggested something
similar earlier).  If you can be more specific I'll be glad to try whatever you
ask.

>  > did the minibuffer frame ever receive the focus, after
>  > `read-from-minibuffer' was invoked?  That's the question 
>  > that I think we are assuming different answers to.  I'm
>  > guessing yes, and I think you are saying no.
>  > I'm guessing yes, but then the window mgr gave the focus 
>  > instead to the new frame it created.
> 
> So you mean the following happens:
> 
> (1) Emacs ask a `yes-or-no-p' with input focus directed to frame A.
> 
> (2) The window manager redirects focus to the new frame B and the
>      `handle-switch-frame' which should redirect focus from B 
>      to A gets delayed as long as Emacs waits for minibuffer input.

I didn't mean that, but maybe that's what happens.

All I meant was that (I'm guessing that):

a. Emacs asks the question, directing focus to the minibuffer frame for the user
to input a response.

b. MS Windows creates the new frame and gives it the focus, taking the focus
away from the minibuffer.

>  > OK.  What's needed I guess is to make sure somehow that 
>  > every frame redirects input to the minibuffer frame when
>  > the minibuffer becomes active.
> 
> Which won't help in (2) above.

Right, and maybe not in my supposition either.

>  > Perhaps it would help to imagine the new frame scenario a 
>  > bit like the switch-to-*Completions*-frame scenario (dunno).
>  >
>  > As I mentioned in my other reply today, you can, when the 
>  > minibuffer is active, explicitly switch the focus to the
>  > *Completions* frame, to do something there
>  > (e.g. move to some completion candidate).
> 
> Which function precisely does that?

With just oneonone.el loaded (which creates a standalone minibuffer and
special-display *Help* and *Completions*, with the latter frame redirected to
the minibuffer frame), even just `C-x o' during completion will do it.  I.e.,
from the minibuffer, `C-x o' moves you (focus) to *Completions*.

Or you can click *Completions* with the mouse - same effect.

In Icicles, you can use C-<insert> to flip back and forth between the minibuffer
and *Completions*.  C-<insert> is command `switch-to-*Completions*' in the
minibuffer completion keymaps, and C-<insert> is command
`icicle-insert-completion' in keymap `completion-list-mode-map'.