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

[martin rudalics]

> 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