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

[martin rudalics]

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