>> Sorry.  Do (defalias 'yes-or-no-p 'y-or-n-p) and then try.
 >
 > Are you sure you mean that?  AFAIK, `y-or-n-p' is not at all representative - it
 > does not even use the minibuffer, I think: it just reads events directly.  I
 > will try to do as you instruct, if you confirm, but I do not understand how
 > using `y-or-n-p' here can possibly help.

Because you can do `select-frame-set-input-focus' with it.

 >> ... what command is C-] bound to?  I can't type it on my keyboard ...
 >
 > `abort-recursive-edit'.  `C-]' is the (only) default global binding (emacs -Q)
 > for `abort-recursive-edit'.

My keyboard doesn't allow me to input things like C-] easily so I don't
know what these do.

 >> But it does work with emacs -Q on your system, I suppose?
 >
 > I'm not sure just what the test was to be here.  But I tried with emacs -Q (plus
 > loading cygwin-mount.el & setup-cygwin.el, so that I have a bash shell on
 > Windows).
 >
 > I tried first with nil `pop-up-frames' - that behaved normally, i.e., as it
 > should.  I tried then with non-nil `pop-up-frames' - and that manifested the
 > same problem that I reported!  Good news!

If you get the problem with `pop-up-frames' t and not with the special
display settings we have simplified the problem.

 > The informative buffer *Process List* is popped up in a separate frame, which
 > apparently gets the focus.  The question about killing active processes appears
 > in the minibuffer of the original frame (which has only buffer *shell*).
 >
 > Because the new frame has the focus, _you cannot answer the question_.  You are
 > forced to select the frame with the question (e.g. clicking mouse-1 on its title
 > bar), in order to answer it and exit Emacs.

OK.

 > A second bug (I think) is that there is NO feedback/response to your typing the
 > answer.  With focus in the *Process List* frame, which has a read-only buffer, I
 > would expect an error message saying that the buffer is read-only.  But you get
 > NO message - nada.  Not only that, but I see no such message in buffer
 > *Messages* if I look there.  Dunno why this is.

I suppose that as long as you don't type either yes or no in the
original frame nothing happens at all.

 >> So the problem seems that input doesn't get redirected to your
 >> minibuffer frame when popping up a new minibuffer-less frame.
 >
 > Seems to not depend on a standalone minibuffer frame, but yes, that seems to be
 > the problem.

Agreed.

 > Well, that's one problem, anyway.  Really, I do not want the new frame popped up
 > to have a minibuffer and pose the question about killing processes.  I want the
 > new frame to just be displayed and _not selected_ for input/output (user
 > interaction).  I do not want it to have a minibuffer.

But we must select a frame for answering the question.

 > More precisely, I don't have much of an opinion in the case of a non standalone
 > minibuffer.
 >
 > But in the case of a standalone minibuffer, it definitely should continue to
 > have the input focus.  That's the point, for me.

Why "continue"?  You could invoke C-x C-c in any frame.

 > It would not be a solution for me to give the new frame its own minibuffer or
 > something and to let it keep the input focus.  The user should be able to always
 > look to the same, standalone minibuffer - the *only* minibuffer area - for all
 > prompts and user replies.

We'll see to that.

 >>  > 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.
 >>
 >> That's hardly surprising: With `pop-up-frames' t you shouldn't get a
 >> dedicated window, I suppose.
 >
 > Uh, if you are saying what I think you are saying then I'm afraid I disagree
 > strongly about that.  To me, that would be a regression.

Don't be afraid.  I meant with `pop-up-frames' t and
`special-display-buffer-names' and friends nil.

 > I'm sorry; I was probably confused in saying that.  I must have meant that it
 > works with the patch I sent, which (I thought) was applied to Emacs (or was
 > going to be applied).
 >
 > If I use Dired+ (which does what my patch does) then there is no problem, so in
 > my daily use this is solved for the Dired but reported, but not in general (viz.
 > this bug wrt quitting with active processes).

But your patch doesn't address the input focus issue or am I missing
something?

 > If you want a standalone minibuffer frame to have the _only_ minibuffer then you
 > must do everything at load time, i.e., in .emacs.

So this makes debugging more difficult for people who are not used to
work with minibuffer-only frames.

I have attached another version of `with-temp-buffer-window' which now
explicitly shifts input focus to the frame selected at the time the
macro is called.  I hope this will fix the `pop-up-frames' t scenario.
I'm afraid it will not fix the problem when you invoke C-x C-c in any
window but the minibuffer-only window so we probably have to fix that
issue separately.  Please try it.

martin