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

From: martin rudalics <[email-masked]>
Date: Thu, 19 Jul 2012 12:42:10 +0200

>> Can a minibuffer-less frame get the focus?
 >
 > In what scenario?  I don't know what you are asking.
 >
 > Of course a minibuffer-less frame can get the focus either programmatically (a
 > function executing in the minibuffer can select another frame) or through user
 > interaction (the user can click another frame, etc.).

Here and everywhere else I meant focus redirection for interaction with
the minibuffer.  Obviously `redirect-frame-focus' can redirect focus to
a minibuffer-less frame.  But choose_minibuf_frame has this

       /* I don't think that any frames may validly have a null minibuffer
	 window anymore.  */
       if (NILP (sf->minibuffer_window))
	abort ();

and read_minibuf calls choose_minibuf_frame, so if a new frame doesn't
have a valid minibuffer window, emacs should abort.  If it does, the
latter

   if (!EQ (mini_frame, selected_frame))
     Fredirect_frame_focus (selected_frame, mini_frame);

in read_minibuf should redirect focus but apparently it doesn't.

 >>  >> So `1on1-fit-minibuffer-frame' assumes that the selected
 >>  >> frame is the standalone minibuffer frame and that that
 >>  >> frame has focus.  Why don't you verify all that in the
 >>  >> function's body?
 >>  >
 >>  > See above - you already asked that.  It _is_ the
 >>  > minibuffer frame for the call that I expected.  I did not
 >>  > expect the second call provoked by the frame switch
 >>  > command (via post-command-hook), with the wrong frame focused.
 >>
 >> Can you check somehow that the minibuffer-less frame is focussed?
 >
 > Again, I don't know what you mean, or how to do that.

Probably by checking whether the focus of the minibuffer-less frame A is
redirected to the minibuffer-equipped frame B.

 >>  > No, I meant only that the minibuffer was still active:
 >>  > accepting typed input.
 >>
 >> When?
 >
 > Let's not get confused with the language here.  I was not talking about the
 > minibuffer _frame_ accepting input, i.e., having the focus.  That is of course
 > the problem.
 >
 > I was talking only about the minibuffer still being active (not exited)

But what does that mean in practice?  Apart from looping.

 > and
 > `read-from-minibuffer' still expecting input.

Obviously so.

 > It is still my guess that the focus _was_ directed to the minibuffer for/by
 > `read-from-minibuffer', but that thereafter the new frame was popped up and the
 > window mgr gave it the focus (i.e., took focus away from the minibuffer frame).

 From the window manager's POV the minibuffer-less frame does have
focus.  The emacs redirection mechanism works on top of that.

 > No, I do not have any proof of that, but that's my conceptual model so far.
 >
 > But you understand this stuff at a better, lower level than I: you understand it
 > at the level of windows etc.

I understand next to nothing about WM windows.

 > It is no doubt correct to speak of the minibuffer
 > window and not (as I did, waving my hands) of the "minibuffer" expecting input.

It makes a difference if you have a minibuffer-less frame that has no
minibuffer window it can direct input to.

martin