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

[martin rudalics <rudalics@gmx.at>]

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

Sorry.  Do

(defalias 'yes-or-no-p 'y-or-n-p)

and then try.

 > C-x C-c still did nothing when I typed an answer to the prompt about active
 > processes.  And again, when I hit C-]

... what command is C-] bound to?  I can't type it on my keyboard ...

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

But it does work with emacs -Q on your system, I suppose?  So the
problem seems that input doesn't get redirected to your minibuffer frame
when popping up a new minibuffer-less frame.

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

That's hardly surprising: With `pop-up-frames' t you shouldn't get a
dedicated window, I suppose.

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

Things would get simpler if you were able to supply a reasonably small
file to test this so we wouldn't always have to get through your entire
setup and completely lose our testing environments.  For me, debugging
and testing things with emacs -Q is already hard enough.

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

Then why do you suggest at the beginning of the current thread to

 >> "look to `dired-mark-pop-up' which does something similar but gets it right"

if it apparently doesn't get it right anyway?

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

It would be fine if we were able to sketch the problem as follows: If a
user has a

(1) minibuffer-only frame and all other frames use that minibuffer and

(2) a `yes-or-no-p' or `read-from-minibuffer' prompt pops up in a
     separate frame

then `select-frame-set-input-focus' is needed to redirect input to that
minibuffer-only frame inorder to answer the question.  Can't you try to
provide a test example on this basis?  The Elisp manual doesn't help me
at all when I try doing that.  For example, if I want to know how to use
`set-minibuffer-window' for setting up the minibuffer-window to use for
a minibuffer-less frame, I'm completely lost.  If with emacs -Q I do

(let ((frame-1 (make-frame '((minibuffer . only))))
       (frame-2 (make-frame '((minibuffer . nil)))))
   (set-minibuffer-window (frame-root-window frame-1)))

then I still can't delete the initial frame because the
minibuffer-window for frame-2 is that of the initial frame.

martin