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

From: martin rudalics <[email-masked]>
Date: Tue, 24 Jul 2012 14:46:55 +0200

>> (progn
 >> ;;  (setq minibuffer-auto-raise t)
 >> ;;  (setq pop-up-frame-function
 >> ;;        (lambda () (make-frame '((minibuffer . nil)))))
 >>    (setq pop-up-frames t)
 >>    (add-hook 'after-make-frame-functions
 >> 	    #'(lambda (frame)
 >> 		(redirect-frame-focus frame frame)))
 >>    (shell))
 >>
 >> where the two forms in comments are optional.  In all cases, focus is
 >> redirected appropriately after C-x C-c (although I think that when the
 >> new frame does have a minibuffer window, no redirection should be done
 >> at all and the prompt should appear in the new frame - but it seems
 >> difficult to get that right).  And obviously things look better with
 >> `minibuffer-auto-raise' non-nil.
 >
 > Yes, if I try that with emacs -Q then it does what you say (with Emacs 24.1 and
 > later).
 >
 > And uncommenting those two lines also behaves as I think you intend.  In both
 > cases, the question is posed, and the response is accepted, in the minibuffer of
 > frame *shell* (i.e., not the minibuffer of frame *Process List* in the case
 > where it has one).
 >
 > But if *Process List* has no minibuffer (uncommented test case), and it is
 > selected (e.g., later, manually, after replying "no" once) when you hit `C-x
 > C-c' (i.e., the second `C-x C-c'), then frame *shell* is raised and receives the
 > input, even though there is nothing on that frame that the user needs to see
 > (apart from the question/answer).

This is probably the case where a window on another frame is reused
before asking the `yes-or-no-p' question.  This should be easier to
handle because the window manager supposedly won't focus that frame.

In any case I think a `yes-or-no-p' question should terminate by
killing the *Process List* buffer to avoid such confusion.

 > It is better, IMO, for the question/response to be in frame *Process List*, as
 > we discussed earlier.  (This is all for the case where there is no standalone
 > minibuffer frame.)

I think so too.

 > The reason I provided the description I did was that I thought we were talking
 > about my setup with a standalone minibuffer frame.  See my previous description
 > (quoted above) for what happens in that context.  For that context, your
 > suggestion of using `after-make-frame-functions', as I understood it, did not
 > help.

What precisely is the problem with it?

martin