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

[martin rudalics]

>>  > 1. When I do C-x C-c, and respond to the yes/no question,
>>  > it seems I must wait a tiny bit before typing yes/no.
>>  > Otherwise, the first char (e.g. `y') is lost, so
>>  > I end up with just `es' (I see the `y' nowhere).  Not a
>>  > big deal; just FYI.
>>
>> Does this happen _only_ with your code or also in the emacs
>> -Q scenarios _without_ your code?  What happens with a
>> `y-or-no-p' defalias?
>
> Not sure what you mean.  There is no equivalent in the emacs -Q tests you 
asked
> me to do.  There is nothing on post-command-hook etc.

So the delay is due to processing `post-command-hook'?

>> That's a bad idea in my opinion.  Redirect as soon as possible.  Why
>> don't you use `after-make-frame-functions'?
>
> I'm not sure what you mean.  I tried this:
>
> 1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'.
>
> 2. Put back the guard (eq last-event-frame (window-frame (minibuffer-window)))
> at the beginning of `1on1-fit-minibuffer-frame' (so it is a no-op otherwise).
>
> 3. Defined this and added it to `after-make-frame-functions':
>
> (defun 1on1-redirect-to-minibuffer (new-frame)
>   "..."
>   (when (and 1on1-fit-minibuffer-frame-flag
>              (active-minibuffer-window)
>              (save-selected-window
>                (select-window (minibuffer-window))
>                (one-window-p nil 'selected-frame)))
>     (redirect-frame-focus
>       new-frame
>       (window-frame (minibuffer-window)))))
>
> That did not help at all.  The original symptoms returned (typing yes/no did 
not
> go to the minibuffer etc.).

Here (Emacs 24.1 release because trunk crashes to frequently these days)
I can do something like

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

martin