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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11939 <at> debbugs.gnu.org
Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus
	whenit	calls	`list-processes'
Date: Sun, 29 Jul 2012 15:55:28 +0200

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

I don't know.  read_minibuf does (my remarks appear below the code):

  /* Choose the minibuffer window and frame, and take action on them.  */

  choose_minibuf_frame ();

  record_unwind_protect (choose_minibuf_frame_1, Qnil);

I don't understand the last two calls, IMHO one of them seems redundant.

  record_unwind_protect (Fset_window_configuration,
			 Fcurrent_window_configuration (Qnil));

I don't know which frame is selected here in your case.

  /* If the minibuffer window is on a different frame, save that
     frame's configuration too.  */
  mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
  if (!EQ (mini_frame, selected_frame))
    record_unwind_protect (Fset_window_configuration,
			   Fcurrent_window_configuration (mini_frame));

But this should restore the configuration of your minibuffer frame.  I
don't have the slightest idea whether and how the selected window is
preserved provided it's on another frame.  You could try checking via
`minibuffer-setup-hook' and `minibuffer-exit-hook' but I'm afraid the
latter is executed too early and you're still in the same state of
affairs as in the setup hook.  Are you stuck in the minibuffer window
even when you do `top-level'?

> 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.

If this were the case, we'd have a bug.  But the code doesn't indicate that.

martin

Previous Next

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