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

["Drew Adams" <drew.adams@oracle.com>]

>  >>  >> Usually, each frame must have a minibuffer window.  How
>  >>  >> else should `read-minibuffer' work?
>  >>  >
>  >>  > It can read from the minibuffer in a standalone minibuffer frame?
>  >>
>  >> Is this a question or an answer?
>  >
>  > An answer, followed by "Is that not correct?", since I'm 
>  > not sure we're talking about the same thing.  I would expect that
>  > it is obvious to you too that Emacs can read from a minibuffer in a
>  > standalone frame.  And it's not clear to me why
>  > that possibility is not an answer to your question.
> 
> But then you didn't answer my initial question.  I didn't ask about
> standalone frames only, I asked about "each" frame.

I was saying only that using a standalone minibuffer frame is a case where it is
not true that each frame has a minibuffer.  And yet it is a case works.  That's
all I was pointing out.

Whether a frame with nil `minibuffer' parameter might actually have a minibuffer
_window_ is not something I know about, as I said.  I'm sure I'm not saying
anything here that you are not aware of, so if this part is only a word game for
you then let's move on, please.

>  >>  > That's what I was guessing, that a frame's `minibuffer'
>  >>  > parameter might be non-nil but it somehow has a minibuffer
>  >>  > _window_.  Seems odd, but I guess these things are at two
>  >>  > different levels.  I am used to the Lisp & frame level - I
>  >>  > know almost nothing about the C & window level.
>  >>
>  >> Emacs must be able to work internally even if you make 
>  >> all your frames minibuffer-less.
>  >
>  > I never claimed otherwise.  But I don't see the relation 
>  > here.  And I do not make all my frames minibuffer-less.
>  > So I guess I'm not following you very well.
> 
> When you exit emacs deleting its last frame, there might be an internal
> state where only a minibuffer less frame remains.  And that may cause
> a(n unwanted) crash IIUC.

OK.  Do you see me saying anything that contradicts that?  I do not understand
what the point is here - what it is that we are discussing.  I am not disputing
anything I hear you to be saying.

>  >>  >> `mouse-leave-buffer-hook' and in a `pre-' or
>  >>  >> `post-command-hook' check whether that something got executed.
>  >>  >> Then you can be sure that somewhere in between a
>  >>  >> `handle-switch-frame' interfered.
>  >>  >
>  >>  > Sorry, I don't follow you (and I haven't found where you
>  >>  > suggested something similar earlier).  If you can be more
>  >>  > specific I'll be glad to try whatever you ask.
>  >>
>  >> When you want to check of `handle-switch-frame' executions you cannot
>  >> trace otherwise and you do not run emacs in the debugger, the most
>  >> simple way to trace these is to put some function on
>  >> `mouse-leave-buffer-hook', and inspect the output of that
>  >> function later on.
>  >
>  > OK, but I still do not know what you would like me to 
>  > do/test.  Can you give me a recipe to test?
> 
> No.  All I did was to reply to an issue you raised earlier - that of
> `handle-switch-frame' possibly interfering with "normal" execution of
> commands.  And I said that IMHO the most simple way to notice whether
> `handle-switch-frame' got executed in between is to put a function on
> `mouse-leave-buffer-hook'.

I see.

But as I said earlier, I already determined that `h-s-f' was in fact the current
(i.e., last) command when `1on1-fit-minibuffer-frame' kicked in from
`post-command-hook'.