GNU bug report logs - #11939
24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11939 <at> debbugs.gnu.org
Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls	`list-processes'
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.