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

[Drew Adams]

>  >> and with your usual settings and tell me what you see.  
> 
> You should have tried #1 and #2 with emacs -Q.

Sorry, I thought that's what you meant by "with your usual settings".

> Otherwise, your private settings will shadow #1 and #2 
> (I tested #1 and #2 here but would like a confirmation).

#1 (emacs -Q): No problem.

#2 (emacs -Q): Does not work. The *Process List* frame is in front, and the
question is posed in the minibuffer of the *shell* frame.  Typing seems to go
nowhere, but when I hit RET after typing I get this error msg:

yes-or-no-p: Buffer is read-only: #<buffer *Process List*>

Interestingly, If I then try C-x C-c from *Messages*, after manually bring that
frame to the front, then again *Process List* is moved to the front and the
question is posed in the *Messages* frame.  I expect that info might help, and
perhaps you guessed already that that would happen.

> You did not report whether it works for `minibuffer-auto-raise' nil.
> Can you look into that?

It is nil by default, no?  So the tests for #2 test that.

But #1 with the value nil works also.  The only difference is that with the
value nil the *Process List* frame is foremost (in front), and with it t the
*shell* frame is in foremost.

It's a choice, I guess, whether it is more important to see all of the question
(prompt) or to see the *Process List* buffer completely.  I'm not sure I have a
settled opinion about that.

In the case of emacs -Q, where there is no standalone minibuffer frame, I think
the best behavior (if possible) would be to have the question appear in the
minibuffer of the *Process List* frame (and have that frame be foremost).

In the case of a standalone minibuffer frame, the best behavior is probably to
always have the minibuffer frame foremost (at least when it asks a question).
Typically, a user with a standalone m. frame has it positioned out of the way as
much as possible.  In my case, for instance, it stretches across the bottom of
my screen (and new frames are popped up by the window mgr at or near the top of
the screen).

>  > Perhaps the crash you see is related to bug #11984, which 
>  > I see mentioned in passing?
> 
> No. The crash happens because the following assumption in frame.c
> 
>         /* We know that there must be some frame with a minibuffer out
>            there.  If this were not true, all of the frames present
>            would have to be minibufferless, which implies that at some
>            point their minibuffer frames must have been deleted, but
>            that is prohibited at the top; you can't delete surrogate
>            minibuffer frames.  */
>         if (NILP (frame_with_minibuf))
>           abort ();
> 
> does not always hold during the exit dialogue.  And it's bad 
> because it crashes Emacs when I try to avoid the exit because
> of a running subprocess.

Got it.  I don't get a crash (on MS Windows).  Are you seeing the crash on MS
Windows also?

> Trivial.  At the time you wrote the "fixes" you had "fixed" it already
> by doing something else.  Now you "just" have to find out 
> what else you did then ;-) Are you sure you ran your changes without
> my file loaded?

No, I'm not sure.  In fact, I thought about that after sending my last mail (I
was tired at the time).  And looking over the thread I see now that I must have
been loading your (earlier) code also.  The problem I was looking into at the
time was why your code made things work with emacs -Q but not with my setup.
The fix to my code no doubt enabled your fix to do its job.

But I thought that I had tested with all Emacs versions, and they all worked
after my fix.  I'll have to revisit this when I get some time.  I imagine that
your code is applicable only to Emacs 24+ (is that right?), so it could not have
helped fix things with my setup for other Emacs versions.

> If you use Emacs 24.1 without my changes, then `list-processes' will
> pop up a new frame and give it focus.  When it now asks the `y-or-n-p'
> question you _are_ lost if the new frame does not have a minibuffer and
> you can't redirect it to one.

Got it.  What about other Emacs releases - are relevant at all in this context?
Should we expect that your code can help them also?

>  > All that happens is that `1on1-fit-minibuffer-frame' does 
>  > nothing, and that does not help with the frame focus problem.
>  > Similarly if I, instead of that test, add the call to
>  > `select-frame-set-input-focus' at the end of the function - that
>  > too no longer is a fix.
> 
> Try explicitly redirecting the focus from the new frame to the
> minibuffer-only frame via `redirect-frame-focus'.

Where?  At the end of `1on1-fit-minibuffer-frame', instead of
`select-frame-set-input-focus'?

And would this be in order to try to make things work even without your code
(e.g., for older Emacs versions)?  Because if not I do not need to do it, since
the code I have now already works well in Emacs 24, when I use your code also.

IOW, I'm not clear what you are suggesting, and what problem it might solve.  If
it is a possible cure for the problem in other Emacs versions, e.g. without your
code, then I'll definitely try it.

> Une solution peut en cacher une autre.

:-D   Ca y est.