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

Previous Next

Full log

Message #44 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 when it
	calls	`list-processes'
Date: Mon, 16 Jul 2012 09:36:35 -0700

> With emacs -Q evaluate
> (progn
>    (setq pop-up-frames t)
>    (load "~/with-temp-buffer-window.el")
>    (shell))
> type C-x C-c, and tell me what happens.

Same behavior as the other emacs -Q recipe that manifested the problem:

The question about killing processes is shown in the minibuffer of the frame
with buffer *shell*.  Buffer *Process List* is popped up in a new frame, which
is apparently selected for focus (by MS Windows).  Typing yes/no has no effect
and there is no feedback, presumably because the wrong frame receives the input.

(I cannot tell the order between the behavior described in the first and second
sentences.  They seem to happen about the same time)

And if you click mouse-1 in the echo area of the *Process List* frame then
*Messages* is popped up in a new frame, confirming that there is no active
minibuffer there.

So now we have two recipes from emacs -Q, one with the code you sent.

BTW, if, after the kill-processes question is posed, I hit C-x C-c again (no
reason to do that, but I did, just to see) then I get this message:

  "window-normalize-window: #<window 8> is not a live window"

and the frame with *Process List* disappears.

Dunno whether this extra info helps at all, but I found it curious behavior.

Previous Next

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