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 it calls	`list-processes'
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

Previous Next

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