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

From: martin rudalics <[email-masked]>
Date: Sat, 14 Jul 2012 18:19:59 +0200

> In the problematic contexts, a new frame is popped up and given the focus (by MS
 > Windows).  That is apparently somehow different from starting from a frame that
 > already has the focus.

OK.  What happens if in in `yes-or-no-p' you use

                     (when minibuffer-auto-raise
                       (select-frame-set-input-focus
		       (window-frame (minibuffer-window))))

instead of `raise-frame'?

 > If I had to guess blindly, I'd guess that it has to do with the
 > timing/sequencing of things: Maybe in the problematic case the question is FIRST
 > posed in the minibuffer/echo area (giving the minibuffer frame focus) and THEN
 > the new frame is popped up and it gets the focus.

I suppose `handle-switch-frame' is called after the `yes-or-no-p'.  Then
even the `select-frame-set-input-focus' would not help.

 > Whereas maybe in the case I just tested the focus never comes back to the frame
 > that originally had it - once the focus goes to the minibuffer frame, there is
 > nothing that puts it back in the original frame.  Just a hunch.
 >
 > If that is the case, maybe a fix (ugly hack) would be to do this: Whenever the
 > minibuffer frame has focus and some other frame is created, immediately return
 > focus to the minibuffer frame.  (Dunno _how_ that might be done.)

What happens if in `with-temp-buffer-window' you add a
`save-selected-window' around

        (with-current-buffer ,buffer
	 (setq ,value (progn ,@body))
	 (setq ,window (temp-buffer-window-show ,buffer)))

 > Or perhaps look to what Dired does...

Dired uses a `save-window-excursion' which doesn't deal with the frame
but restores the selected window - maybe that's the reason.

 > 1. FYI - I can test only with 24.1, not something later, since other bugs still
 > prevent my using the later Windows builds.  I'm still waiting for a build more
 > recent than 2012-07-02.  Dunno whether this matters here.

What I sent should work with 24.1.

 > 2. I tried to quit Emacs (C-x C-c) after creating a shell buffer (which is in a
 > dedicated window in a separate frame).
 >
 > The informative buffer that lists the active processes was popped up correctly
 > in a separate frame as the yes-or-no question was asked.  But when I tried to
 > type yes or no, that typed input appeared nowhere.
 >
 > I would guess, from the fact that Windows gives the new frame the input focus,
 > that that new frame had the focus and the input was trying to go there.  But
 > that buffer is created read-only and I saw no error message indicating that
 > Emacs was trying to insert the input (yes/no) into a read-only buffer.  No
 > feedback at all - it's as if my typed input was silently sent to /dev/null.
 > (That in itself is not good.)
 >
 > In any case, what's important is that the typed input did not go to the
 > minibuffer frame.

Can you try with just `pop-up-frames' t, that is, disabling special
display buffers?

 > [...]
 > I thought that the patch I sent for this was going to be applied to Emacs - but
 > it never was.  I use this code everyday, with no problem.  But the dialog is
 > still broken in vanilla Emacs.

I understand your concerns.  But we have to first find out why your
system behaves differently and then try to find a general solution.

BTW, has bug#11566 been resolved meanwhile?

martin