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

[martin rudalics]

> (But the *Process List* frame that was popped up was completely
> hidden behind the frame that was selected when I hit C-x C-c.  That's not 
good.)

Because that code was for experimental purposes only.  It's not the task
of `with-temp-buffer-window' or its callers to handle that.  The problem
is elsewhere.  I attach the first version of `with-temp-buffer-window',
however, with a redefined `y-or-n-p'.  Try it with your code but with
`yes-or-no-p' aliased to `y-or-n-p'.

Here, with emacs -Q

(progn
  (defalias 'yes-or-no-p 'y-or-n-p)
  (load "~/with-temp-buffer-window.el")
  (shell)
  (setq minibuffer-auto-raise t)
  (setq pop-up-frame-function
        (lambda () (make-frame '((minibuffer . nil)))))
  (setq pop-up-frames t))

C-x C-c creates a minibuffer-less frame for *Process List* and
redirects the prompt to the initial *shell* frame.  Not 100% perfect
because the *shell* frame partly obscures the *Process List* frame but
this could be tweaked with a better `pop-up-frame-function'.  With the
more conventional

(progn
  (defalias 'yes-or-no-p 'y-or-n-p)
  (load "~/with-temp-buffer-window.el")
  (shell)
  (setq pop-up-frames t))

the prompt appears in the *Process List* window.

So I suppose that we should (at least optionally) have all functions
accessing the minibuffer redirect frame focus to it first.

martin

with-temp-buffer-window.el
Description: application/emacs-lisp