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'losesminibufferfocuswhenitcalls`list-processes'
Date: Tue, 14 Aug 2012 11:10:38 +0200

> It turns out that the problem was 3-fold.  That is, there were three places in
> the code of `1on1-fit-minibuffer-frame' that caused the problem: each was
> _alone_ capable of causing the problem, so all three needed to be fixed.  Here
> they are.
>
> 1. This was one of the guards of the body of `1on1-fit-minibuffer-frame':
>
> (save-selected-window
>   (select-window (minibuffer-window))
>   (one-window-p nil 'selected-frame))

Any reason why you don't use

(one-window-p nil (window-frame (minibuffer-window)))

here?

> The call to `save-selected-window' somehow gave the focus to the *Completions*
> frame.  The solution was to change `save-selected-window' to
> `save-window-excursion' here.  I don't know why, but I'm hoping you will.

You mean that `save-select-window' can redirect focus and not direct it
back to where it was before calling it?  If this is the case, please
check whether it happens in Emacs 23 as well and file a bug report
(without referencing `1on1-fit-minibuffer-frame', if possible).

> 2. This was called near the beginning of the `1on1-fit-minibuffer-frame' body:
>
> (let* ((frame (save-selected-window
>                 (select-window (minibuffer-window))
>                 (selected-frame)))

Do you mean

(window-frame (minibuffer-window))

here?

> The fix here too was to use `save-window-excursion' instead of
> `save-selected-window'.

Same as above.

> 3. At the end of the `1on1-fit-minibuffer-frame' body there is this call:
>
> (1on1-set-minibuffer-frame-top/bottom)
>
> The code for that function is this:
>
> (defun 1on1-set-minibuffer-frame-top/bottom ()
>   (when 1on1-minibuffer-frame
>     (condition-case nil
>         (if (fboundp 'redisplay)
> 	    (redisplay t)
> 	  (force-mode-line-update t))
>       (error nil)) ; Ignore errors from, e.g., killed buffers.
>     (modify-frame-parameters
>      1on1-minibuffer-frame
>      `((top ,@ (or 1on1-minibuffer-frame-top/bottom
>                    (- (* 2 (frame-char-height
>                              1on1-minibuffer-frame)))))))))
>
> Here the problem was the call to `redisplay'.  I changed (foundp 'redisplay) to
> just nil to fix things - `force-mode-line-update' works without changing the
> focus.
>
> `redisplay' is defined in C code.  I do not know why it causes a problem here
> (why would redisplay change the input focus?), and I don't know what the proper
> solution might be, except to just use `force-mode-line-update' as I was already
> doing in older Emacs versions (which do not have `redisplay').
>
> Do you have an idea about this?  Does any of this make sense to you?

No.  Can't you distill a simple test case?  `redisplay' shouldn't care
about frame focus either.

> Each of these fixes is needed for `1on1-fit-minibuffer-frame'.  Reverting any of
> them brings back the problem (giving *Completions* the focus).  I do not
> understand any of these fixes (why they work), and I am certainly not claiming
> anything about them or about the problem, which I do not understand.  I am only
> saying that together these changes fix the problem I encountered.
>
> But if you can explain things I will be glad to learn.

I can't explain any of these.  In the past, I tried to make most window
functions work on any window/frame to work independently from the
selected window.  Earlier, selecting a window must have been a very
simple procedure.  Nowadays, this incurs so many side-effects in the
window/frame/display area that you should try to avoid `select-window'
wherever possible.

martin

Previous Next

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