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

[martin rudalics <rudalics@gmx.at>]

 >>  > Something like this:
 >>  > (with-unfocused-buffer-displayed BUFFER &body BODY)
 >>  >
 >>  > where BUFFER is displayed for information only, and where
 >>  > BODY would include the call(s) that read from the minibuffer.
 >>  >
 >>  > The current buffer would remain what it was beforehand,
 >>  > and _if_ BUFFER gets displayed in its own frame and _if_
 >>  > there is a standalone minibuffer frame, _then_ the focus
 >>  > for BUFFER's frame gets automatically redirected to the
 >>  > minibuffer frame.
 >>
 >> In my experience, this requirement is met if the construct requests
 >> input with BUFFER's window temporarily selected and BUFFER
 >> temporarily current.  Or am I missing something?
 >
 > Sorry, I don't know what that means.  Perhaps give an example of what you mean
 > by temporarily selected and current?

Temporarily selected means selected via `with-selected-window' and
temporarily current means `with-current-buffer'.

 >>  > handling needed - the construct can essentially be a no-op
 >>  > in that case (AFAICT).
 >>  >
 >>  > How something like this would be implemented I'm not sure.
 >>  > When the redirection would need to take place, to DTRT,
 >>  > I'm not sure.  Perhaps it would need to be done more than once.
 >>  >
 >>  > But an important further requirement is that nothing
 >>  > should prevent Emacs code in BODY or called from within
 >>  > BODY from switching the input focus to BUFFER's frame.
 >>
 >> I don't understand what BODY should contain.  Would this macro be
 >> responsible for displaying BUFFER?
 >
 > No, not as I was conceiving it.  I suppose that would be a possibility, but I
 > expect it is better to keep buffer display out of it.  That's why I said things
 > like "_if_ BUFFER gets displayed in its own frame".
 >
 > What I had in mind was that the macro would be responsible only for making sure
 > that minibuffer input gets (re-)directed to the minibuffer frame.  And that goes
 > for any code in BODY, including code that might pop up BUFFER.
 >
 > IOW, display of BUFFER would come (if it came) from BODY.
 >
 > But again, I'm just thinking out loud.  And it's probable that you see things
 > that I do not.

No.  Just that I don't have the slightest idea how to write a macro that
modifies the behavior of a `yes-or-no-p' dialog it calls.  read_minibuf
and the code for handling keyboard events do the redirecting.

 >>  > Likewise, nothing should prevent the user from explicitly
 >>  > switching the focus to BUFFER's frame.
 >>
 >> This is part of the `yes-or-no-p' dialog, nothing within the scope
 >> of the construct you propose.
 >
 > Can you elaborate?  I don't follow.

IIUC you want to modify the behavior of `yes-or-no-p' to redirect frame
focus in your sense.

 > No.  Again, during reading from the minibuffer it is quite possible for a user
 > to interact with other buffers and their frames.  I gave the example of
 > *Completions*.  The user can hit a key or use the mouse to change the input
 > focus temporarily to another frame - any frame.
 >
 > When the user does that s?he is executing code within BODY.  It is code that
 > reads from the minibuffer, but also code that implements any commands bound to
 > keys or mouse actions that the user uses during that minibuffer dialog.  That's
 > all I meant.

I'm afraid this gets too complicated for me.  You have to find someone
who understands such scenarios better than me.

 >>  > I do not expect that the problematic use case we've been
 >>  > discussing can be detected and dealt with correctly in an
 >>  > automatic way.  If the programmer intention
 >>
 >> Who is the programmer here?
 >
 > The person who writes the code that reads from the minibuffer, code that might
 > or might not be wrapped in the new macro, i.e., that might or might not want to
 > stipulate that BUFFER is not to receive the input focus.

The person who writes that code expects `yes-or-no-p' DTRT.

 >> I refer to the case where a minibuffer-equipped frame is popped up.
 >
 > I'd rather you didn't.  Let's not bring in new things.

Users with non-nil `pop-up-frames' who don't use minibuffer-only frames
do get a minibuffer-equipped frame popped up.  You can ignore them, I
can't.  And a user who excludes BUFFER from the list of specially
displayed buffers does a perfectly valid thing and can expect Emacs to
handle it as it currently does.

 > I don't know.  The only problems I am aware of for `w-t-b-w.el' are these:
 >
 > 1. Loss of special-displayness (a separate problem, but important if we're
 > talking about `w-t-b-w.el' as it stands now).
 >
 > 2. The fact that it limits itself to display of temporary buffers, whereas the
 > actual problem has to do with the temporary display of buffers.

Because I can safely kill a temporary buffer and remove its frame when
I'm done with the dialog.

 > And as far as you know, is the fact that the minibuffer frame is still used (as
 > it should be) due only to the fact that `yes-or-no-p' is used, or can I expect
 > that the minibuffer frame will be used in general?

Due to the fact that `yes-or-no-p' is called in a special way - with the
new window selected.

 >>  >> `with-temp-buffer-window' avoids that by asking the
 >>  >> `yes-or-no-p' question in the new frame.
 >
 > Dunno why I (or was it you?) said that.  I see the question in the minibuffer
 > frame, not the new frame.  Which is TRT.

To "see the question in the minibuffer frame" I ask it in the new 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.  And I have to remove the
frame because you complained that `save-window-excursion' cannot remove
a popped up frame.  And I can't kill a non-temporary buffer.

 >> The invoking code does not care.  It expects `display-buffer' and
 >> `yes-or-no-p' to take care of this.
 >
 > In the general case it is not `yes-or-no-p'.

It can do anything that reads from the minibuffer.

 > The informational frame?  I'd vote for `delete-frame', at least for my own use.
 > We might want to provide ways for the caller and/or the user to control both
 > what to do with the frame/window and what to do with the buffer.  But maybe
 > `frame-auto-hide-function' would make sense here?

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.

 > Anyway, let's talk about this later.

It's your choice.

martin