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

Previous Next

Full log

Message #245 received at 11939 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 11939 <at> debbugs.gnu.org
Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus
	whenit	calls	`list-processes'
Date: Sat, 28 Jul 2012 08:29:46 -0700

>  > But the point was that the minibuffer buffer was the 
>  > (current-buffer) here, suggesting to me that the minibuffer
>  > frame (and its buffer) was selected.
>  >
>  > Is that TRT?  I didn't think so.  I didn't think that just 
>  > calling `redirect-*' would/should also select the frame and
>  > its buffer.  That is why I said this:
> 
> Just calling `redirect-*' does not select the frame and its 
> buffer.  But `yes-or-no-p' does since otherwise you won't be
> able to type into the minibuffer - here's the relevant piece
> in read_minibuf:
> 
>    /* Display this minibuffer in the proper window.  */
>    Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil);
>    Fselect_window (minibuf_window, Qnil);
>    XWINDOW (minibuf_window)->hscroll = 0;

Well, OK.  But normally, after the input is read the selected window/frame
returns to what it was before the reading.  No?

IOW, yes, it is normal and necessary for yes/no input to be entered in the
minibuffer window, so naturally that window must be selected for the duration of
that user input.

The problem is (apparently) that the minibuffer buffer remains selected after
the reading, i.e., the (current-buffer) is " *Minibuf-0*".  Thus, a subsequent
command such as `C-x k' sees that buffer as the current one.  That has not
happened before - it seems to come as a result of redirecting the frame focus,
but perhaps that is just a catalyst/revealer.

Previous Next

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