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

[Drew Adams]

>  >> I have attached another version of 
>  >> `with-temp-buffer-window' which now explicitly shifts input
>  >> focus to the frame selected at the time the macro is called.
>  >> I hope this will fix the `pop-up-frames' t scenario.
>  >> I'm afraid it will not fix the problem when you invoke 
>  >> C-x C-c in any window but the minibuffer-only window so we
>  >> probably have to fix that issue separately.  Please try it.
>  >
>  > Just what is the recipe to try (e.g. from emacs -Q)?
> 
> With your usual setting load the file and test the shell and the dired
> scenarios.

I might be misunderstanding you, but I did this:

1. Started Emacs with my normal setup (not from emacs -Q).
2. Loaded the code you sent.
3. M-x shell

4. Clicked the title bar of the standalone minibuffer frame, to select it.  (Did
that since you said that your code would not help with the usual case, where
another frame has the focus).

5. C-x C-c

The result was the same as before: typing (e.g. "yes") had no effect.  The
minibuffer frame apparently lost the focus as soon as the new *Process List* was
created.

And when I canceled, the supposed special-display buffer *Process List* was
replaced in its frame by the buffer that was current when I hit C-x C-c.  This
part seems to be the same (separate) bug that I reported wrt *Help*.  In this
case, the special-display buffer *Process List* was defined via
`special-display-regexps' and not (as for *Help*) via
`special-display-buffer-names'.  So it seems there is a general bug that a
special-display buffer is no longer really special-display: its window/frame is
not dedicated as it should be.  Burying its buffer should not replace that
buffer in its dedicated window/frame.  It should remove that window/frame (I
have `frame-auto-hide-function' = `delete-frame').

HTH.  Let me know if I did not understand the recipe correctly.