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

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

> I'm using cmd.exe.

How?  What are you doing to not get this error, which I get when I use emacs -Q
without loading the Cygwin stuff?

 "Spawning child process: invalid argument"

>  >> I suppose that we should (at least optionally) have all functions
>  >> accessing the minibuffer redirect frame focus to it first.
>  >
>  > I thought that was already the case - it seems to be.  In the problem
>  > reported for this bug the minibuffer frame had the focus, but it then
>  > lost it because of a frame switch (I mean, because a new frame
>  > creation by Windows switched the focus).
> 
> As a matter of fact `yes-or-no-p' indirectly calls 
> read_minibuf which does
> 
>    if (!EQ (mini_frame, selected_frame))
>      Fredirect_frame_focus (selected_frame, mini_frame);
> 
> So focus is redirected but somehow this doesn't always work 
> when popping up a new frame.

Yes, that's more or less what I was trying to say.  My guess is still that it
does get redirected but when the frame is popped up the new frame takes the
focus.  IOW, that redirection was from the frame that was selected before the
popped-up frame gets selected/focused.  Just a guess, based on what I've seen.

> In any case, it's not necessary to do the defaliasing,
> `yes-or-no-p' should do the same, in principle.  Moreover, my
> `redirect-frame-focus' call in `y-or-n-p' was silly because I mixed up
> the arguments.  So let's forget about this.

Forgotten.

> I still don't understand the consequences described in the 
> doc-string of `redirect-frame-focus' as
> 
>     A frame's focus redirection can be changed by `select-frame'.
>     If frame FOO is selected, and then a different frame BAR is
>     selected, any frames redirecting their focus to FOO are shifted
>     to redirect their focus to BAR.  This allows focus redirection
>     to work properly when the user switches from one frame to another
>     using `select-window'.

I think that last part means only that focus switches when you select a frame,
even if the previously selected frame was not really selected but had the focus
only via a redirection from the actually selected frame.

>     This means that a frame whose focus is redirected to itself is
>     treated differently from a frame whose focus is redirected to 
>     nil; the former is affected by `select-frame', while the latter is not.

It does not say what does affect the latter.  Not too clear to me.

> so there might be still some surprises around the corner.
> 
> IMHO the thing that's crucial is that if you want to peruse a separate
> minibuffer frame after popping up a new frame, you have to do it from
> the freshly popped up frame.

Sounds reasonable.  What might (?) be good would be to find a way to simply
counteract (undo) the auto-focus/selection of the new frame whenever focus was
in the minibuffer frame (and the minibuffer is active).  IOW, perhaps that can
be done automatically.  Dunno whether doing that systematically would be a good
idea or not (or whether it is easy to do).

> For example, if you pop up a new frame and
> then want to ask a `yes-or-no-p' question, you have to select the new
> frame, issue the `yes-or-no-p' there,

Yes, that would be one way of solving the problem, perhaps, if we could ensure
that that happened.  But the ordering of such events might be fragile - and it
might depend on the platform etc.

> and hope that read_minibuf correctly redirects the prompt to the minibuffer
frame.

My guess is that it does, always.  Again, my guess is that it did that
correctly, but the new frame was then created (the creation might have started
before the read_minibuf, but the new focus took effect after the redirection to
the minibuffer, in any case).  Just a guess.

> If `minibuffer-auto-raise' is non-nil, this will raise the minibuffer
> frame, otherwise it will only redirect input to that frame.  I suppose
> that was already your understanding of this issue but I was surprised
> that issuing the `yes-or-no-p' from an old frame won't work.

I'll have to get to the rest of your message(s) a bit later.  Thx.