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

[Drew Adams]

> OK.  What happens if in in `yes-or-no-p' you use
>                      (when minibuffer-auto-raise
>                        (select-frame-set-input-focus
>                      (window-frame (minibuffer-window))))
> instead of `raise-frame'?

Sorry, I don't understand.  `yes-or-no-p' is coded in C.  Where should I change
a call to raise-frame to instead use the above code?

> I suppose `handle-switch-frame' is called after the `yes-or-no-p'.
> Then even the `select-frame-set-input-focus' would not help.
> 
> What happens if in `with-temp-buffer-window' you add a
> `save-selected-window' around
>         (with-current-buffer ,buffer
>        (setq ,value (progn ,@body))
>        (setq ,window (temp-buffer-window-show ,buffer)))

I tried just that (nothing from above about modifying yes-or-no-p, since I don't
understand what you mean there).  It did not change anything:

C-x C-c still did nothing when I typed an answer to the prompt about active
processes.  And again, when I hit C-] the buffer that was current before C-x C-c
replaced the buffer that lists the active processes in its frame.

>  > Or perhaps look to what Dired does...
> 
> Dired uses a `save-window-excursion' which doesn't deal with the frame
> but restores the selected window - maybe that's the reason.
> 
> Can you try with just `pop-up-frames' t, that is, disabling special
> display buffers?

OK, I tried that: still using my setup, I set `special-display-regexps' to nil
then tried C-x C-c etc.

That changed nothing (except that the popped up buffer appeared in a regular
frame, not a special-display frame).  The symptoms were identical AFAICT: input
did not go to minibuffer, and quitting (C-]) left the frame but put the
originally current buffer in it, replacing the processes-list buffer there.

Oh, it also changed this: Now when I hit `q' in *Help*, instead of the frame
being removed I get another buffer in it, substituted for *Help*.  This in spite
of the fact that `special-display-buffer-names' has this entry, which should
make *Help* be dedicated:

("*Help*" 1on1-display-*Help*-frame
  ((background-color . "Thistle")
   (mouse-color . "Blue Violet")
   (cursor-color . "Blue Violet")
   (height . 40)))

Buffer *Help* is still popped up in a new frame that has those colors, but now
when I hit `q' in it the frame does not disappear and its buffer is changed.
That's not what I would call "dedicated" anymore.  Dunno if there is another bug
here.  HTH.

> I understand your concerns.  But we have to first find out why your
> system behaves differently and then try to find a general solution.

Agreed.

If someone on MS Windows were willing to try oneonone.el (and set
`special-display-regexps' to ("[ ]?[*][^*]+[*]")) then they would likely be able
to see the behavior for themselves.

(Dunno for sure whether other things in my setup are involved.  If someone is
really interested then we can pursue it.)

> BTW, has bug#11566 been resolved meanwhile?

Not at all (not that I know of/can tell).  The last message in that thread is
from me, and its questions were never answered.

My guess is that these bugs are related, if not the same underneath.

[BTW/FWIW, in #11566, there was some discussion of `select-frame' vs
`select-frame-set-input-focus.  I can confirm again that these definitely are
not the same, and the former is not sufficient in some cases, which is why I end
up calling the latter in some contexts.  I noted this mentally a while ago when
I encountered it again, since I recalled then that it had been suggested in that
thread that `select-frame' should be sufficient.]