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

[martin rudalics]

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

with-temp-buffer-window.el
Description: application/emacs-lisp