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

[martin rudalics]

> #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