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

[martin rudalics <rudalics@gmx.at>]

 > #2 (emacs -Q): Does not work. The *Process List* frame is in front, and the
 > question is posed in the minibuffer of the *shell* frame.  Typing seems to go
 > nowhere, but when I hit RET after typing I get this error msg:
 >
 > yes-or-no-p: Buffer is read-only: #<buffer *Process List*>
 >
 > Interestingly, If I then try C-x C-c from *Messages*, after manually bring that
 > frame to the front, then again *Process List* is moved to the front and the
 > question is posed in the *Messages* frame.  I expect that info might help, and
 > perhaps you guessed already that that would happen.

Are you sure you started Emacs again before you went through

(progn
   (setq pop-up-frames t)
   (load "~/with-temp-buffer-window.el")
   (shell))

Here I get a new frame in the foreground, focussed, with the process
list in its root window and the `yes-or-no-p' prompt in its minibuffer
window.  Please try once more.  If this does not work on your system, we
might have a smoking gun.

 >> You did not report whether it works for `minibuffer-auto-raise' nil.
 >> Can you look into that?
 >
 > It is nil by default, no?  So the tests for #2 test that.

It's a NOOP for #2.

 > But #1 with the value nil works also.  The only difference is that with the
 > value nil the *Process List* frame is foremost (in front), and with it t the
 > *shell* frame is in foremost.
 >
 > It's a choice, I guess, whether it is more important to see all of the question
 > (prompt) or to see the *Process List* buffer completely.  I'm not sure I have a
 > settled opinion about that.

Occasionally they obscure each other.

 > In the case of emacs -Q, where there is no standalone minibuffer frame, I think
 > the best behavior (if possible) would be to have the question appear in the
 > minibuffer of the *Process List* frame (and have that frame be foremost).

That's what happens here in scenario #2.

 > In the case of a standalone minibuffer frame, the best behavior is probably to
 > always have the minibuffer frame foremost (at least when it asks a question).
 > Typically, a user with a standalone m. frame has it positioned out of the way as
 > much as possible.  In my case, for instance, it stretches across the bottom of
 > my screen (and new frames are popped up by the window mgr at or near the top of
 > the screen).

In any case, this is what the user may customize via
`minibuffer-auto-raise'.

 > Got it.  I don't get a crash (on MS Windows).  Are you seeing the crash on MS
 > Windows also?

On Windows.

 > But I thought that I had tested with all Emacs versions, and they all worked
 > after my fix.  I'll have to revisit this when I get some time.  I imagine that
 > your code is applicable only to Emacs 24+ (is that right?), so it could not have
 > helped fix things with my setup for other Emacs versions.

Yes.  But maybe you could adapt your buffer display function
accordingly.

 >> If you use Emacs 24.1 without my changes, then `list-processes' will
 >> pop up a new frame and give it focus.  When it now asks the `y-or-n-p'
 >> question you _are_ lost if the new frame does not have a minibuffer and
 >> you can't redirect it to one.
 >
 > Got it.  What about other Emacs releases - are relevant at all in this context?
 > Should we expect that your code can help them also?

If you have an appropriate hook.

 >> Try explicitly redirecting the focus from the new frame to the
 >> minibuffer-only frame via `redirect-frame-focus'.
 >
 > Where?  At the end of `1on1-fit-minibuffer-frame', instead of
 > `select-frame-set-input-focus'?

I think so.

 > And would this be in order to try to make things work even without your code
 > (e.g., for older Emacs versions)?  Because if not I do not need to do it, since
 > the code I have now already works well in Emacs 24, when I use your code also.
 >
 > IOW, I'm not clear what you are suggesting, and what problem it might solve.  If
 > it is a possible cure for the problem in other Emacs versions, e.g. without your
 > code, then I'll definitely try it.

If your `1on1-fit-minibuffer-frame' can hook in after the new frame pops
up, it might be worth a try.  With `temp-output-buffer-show' the only
suitable hook at your disposition is `temp-buffer-show-hook' where
selecting another window won't work because the hook's call is wrapped
in `with-selected-window'.  But you can remember the new frame's window
and select it later, for example, in `post-command-hook'.

martin