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

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 11939 <at> debbugs.gnu.org
Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls	`list-processes'
Date: Wed, 18 Jul 2012 20:54:57 -0700

> I attach yet another version of `with-temp-buffer-window'.  Please
> test it with

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

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.

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

-----

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.

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.

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.

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.

And I'm afraid I'm probably just confusing you now with my current reporting.
Calling it a day now.  If I figure something out I'll let you know.  Sorry for
the confusion.

Thx - Drew

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.