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

[martin rudalics <rudalics@gmx.at>]

 > You seem to be saying that if BUFFER is selected/current, and if input is read
 > somewhere (where?) - then what?  The focus gets automatically redirected to the
 > minibuffer frame?

A BUFFER is not selected, only a window or a frame is.  I say that when
a window on a minibuffer-less frame is selected and its buffer is
current at the time a `yes-or-no-p' question is asked, focus for reading
input from the minibuffer gets redirected to a minibuffer-equipped
frame.

 > This is not about reading input with BUFFER selected/current.  The idea is to
 > have the _previously_ selected buffer be selected/current, while input is read
 > from the minibuffer.  The idea is not to make BUFFER selected/current, but just
 > to display it.

I don't talk about ideas.  I talk about the current implementation of
dialogs that read text from the minibuffer.

 > Beyond that, that sentence of mine was shorthand.  It (apparently) is not enough
 > that the focus be redirected once, at some point, to the minibuffer frame.  It
 > needs to either remain there (somehow preventing MS Windows from moving it away)
 > or be put back there (after MS Windows moves it to BUFFER's frame).

Focus redirection is done by Emacs.  MS Windows won't redirect focus.

 > IOW, even
 > if redirection is happening now as it should, it is not sufficient if, after
 > that redirection to the minibuffer, the OS changes the focus again (to the new
 > frame).

Any redirection is permanent for a frame until it's explicitly changed
by Emacs.

 >> IIUC you want to modify the behavior of `yes-or-no-p' to
 >> redirect frame focus in your sense.
 >
 > I don't know why you mention `yes-or-no-p'.  This is about reading from the
 > minibuffer, in general.
 >
 > I don't want or not want to modify `yes-or-no-p' or `read-from-minibuffer'.  I'm
 > just saying that if the problem is that we want to display BUFFER, and it gets
 > displayed in a new frame, and we want to read from the minibuffer, then we do
 > not want, for that minibuffer reading, the input focus to be in BUFFER's frame.

Above you say that

 > It (apparently) is not enough
 > that the focus be redirected once, at some point, to the minibuffer frame.

so you want to modify `yes-or-no-p' or `read-from-minibuffer'.

 > Yes, when reading from the minibuffer is initiated,
 > the minibuffer frame should get the focus.  But the user (or Emacs) should not
 > be prevented from switching the focus to another frame.
 >
 > All that we are trying to prevent or remedy is the focus switching to another
 > (new) frame by the OS.  We should not be preventing either Emacs or the user
 > from switching focus to another frame, just because the minibuffer is active.
 >
 > That is the only point I was trying to make here.

And my point is that beyond the initial redirection the mechanism
reading keyboard events is responsible for providing such behavior.

 > I did not know where you were asking the question.  By that, I assume you mean
 > that the new frame is selected (and has the focus?) when you invoke
 > `yes-or-no-p'.  Is that right?

I temporarily select the new frame when I invoke `yes-or-no-p'.  The new
frame will be selected again by `handle-switch-frame' if and when Emacs
is notified by the OS.

 > Just for my info, why does it matter where `yes-or-no-p' is invoked?  _Should_
 > it matter, or is it just a fact that we must live with that it does matter?

It does matter if and when the selected frame does not have a minibuffer
and I want to redirect focus to a minibuffer frame.

 >>  > Yes, it is more restrictive than the actual problem encountered.
 >>  > As I said, it might suffice in practice, but there is nothing in the
 >>  > problem description that requires that the buffer itself be temporary.
 >>
 >> I have to kill the buffer to remove the frame.
 >
 > I don't understand why, but probably I don't need to understand everything.  Why
 > doesn't `delete-frame' do what you need?

Because the window is "quit" when the user is done with the dialog.
`quit-window' deletes the frame only if the buffer is killed or
`frame-auto-hide-function' takes over.

 >> And I have to remove the frame because you complained that
 >> `save-window-excursion' cannot remove a popped up frame.
 >
 > Hm.  I don't recall that at all, but I believe you that I did.  Was that in some
 > other thread?

In the thread on the behavior of `dired-mark-pop-up' IIRC.

 >> If we use `frame-auto-hide-function', the caller does not have to kill
 >> the buffer and there's no need to make this construct work
 >> for temporary buffers only.
 >
 > That sounds good to me.  Perhaps I'm missing something.  I don't want to steer
 > you down the wrong path, but what you say here sounds good to me.
 >
 > If the more general case can be handled, then the more restrictive case
 > (temporary buffer, not just temporary display) could presumably be handled also,
 > as a subcase, no?  Or even if not as a subcase, as a separate case.
 >
 > IOW, if possible it would be good to have both possibilities, so a programmer
 > could get the right behavior for a given context: If s?he wants that buffer to
 > be temporary, then call a construct that treats it as such (killing it).  If
 > s?he wants that buffer not to be temporary and only its display to be temporary
 > then call a construct that does that instead.
 >
 >>  > Anyway, let's talk about this later.
 >>
 >> It's your choice.
 >
 > Can we have both possibilities?
 >
 > If not, let's get the temporary-buffer one first.  IOW, I think you have that
 > case almost nailed - there is just the special-display/dedicatedness that does
 > not work yet.

Then have a look at what happens there.

martin