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

[martin rudalics]

> #1
>> (progn
>>    (load "~/with-temp-buffer-window.el")
>>    (shell)
>>    (setq minibuffer-auto-raise t) ; Optional
>>    (setq pop-up-frame-function
>>          (lambda () (make-frame '((minibuffer . nil)))))
>>    (setq pop-up-frames t))
>
> #2
>> (progn
>>    (setq pop-up-frames t)
>>    (load "~/with-temp-buffer-window.el")
>>    (shell))
>>
>> and with your usual settings and tell me what you see.  Also test it
>> with `minibuffer-auto-raise' either nil or t.
>>
>> If the above work, test also the delete files in dired scenario.  The
>> first dialogue will probably fail in the usual way, then you have to
>> load `with-temp-buffer-window.el' once more and try another time.
>
> I used my normal setup.  I tried #1.  No problem.  I started again and tried 
#1
> with nil `minibuffer-auto-raise'.  Still no problem.  I tried #2.  Still no
> problem.

You should have tried #1 and #2 with emacs -Q.  Otherwise, your private
settings will shadow #1 and #2 (I tested #1 and #2 here but would like a
confirmation).

> My setup already has non-nil pop-up-frames, so apparently all that is needed 
is
> your file.  If I comment out the load of your file and try #2 then the bugged
> behavior reappears.
>
> So it seems that you have found a solution.

Since you do set `pop-up-frames' to non-nil you have inirectly confirmed
that it works for your setup.

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

>> Finally, try to exit it in various ways, for example by
>> deleting some frame during the dialogue.
>> I found a not yet 100% reproducible way to crash Emacs doing that.
>
> I could not reproduce that problem.  I was able, after hitting C-x C-c, to 
click
> the corner "X" and thus delete each of the frames.  When I did that on the 
last
> frame (the minibuffer frame), an Emacs popup window gave me the question about
> killing active processes (instead of the question appearing in the 
minibuffer).
> I clicked the Yes button.  Emacs exited normally.
>
> 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.

> But I'm sorry to say that I am totally confused now - not by these recent 
tests
> you've had me do with your code, but by the code fix that I reported for my 
own
> code (on 7/16), where I spoke of 3 fixes, each of which worked.
>
> Now, none of them work.  I am certain that before, when I reported them, that
> each of the 3 fixes worked.  (And the same is and was true for all Emacs
> versions - all worked and now none work.)  I do not understand at all.

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?

> It is true that if I do not add that test of (eq last-event-frame 
(window-frame
> (minibuffer-window))), which is fix one I chose, then the *Process List* frame
> and buffer are current/selected.  But that test does _not_ solve the focus
> problem.  I still cannot type "yes" into the minibuffer frame.

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.

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

> So I am totally confused.  I am glad at least that you seem to have found a
> solution, with your code, for the Emacs 24 case.  I'm disappointed and
> incredulous, however, about my own "fix" that does not work, especially 
because
> it worked (on 7/16) in all Emacs versions.  I have no idea what is going on.

Une solution peut en cacher une autre.

martin