Subject: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'

From: martin rudalics <[email-masked]>
Date: Tue, 14 Aug 2012 18:04:58 +0200

>> Any reason why you don't use
 >> (one-window-p nil (window-frame (minibuffer-window)))
 >> here?
 >
 > The doc for `one-window-p', for Emacs < 24, says this:
 >
 >  "If ALL-FRAMES is neither nil nor t, count only the selected frame."
[...]

IIUC `one-window-p' calls `next-window' ever since with the ALL-FRAMES
argument unchanged and `next-window' has its traditional interpretation
of that argument.  So it seems that the old doc-string was inaccurate in
this regard.  But why you don't you check for yourself?  With Emacs 22

(progn
   (setq old-frame (selected-frame))
   (setq new-frame (make-frame))
   (select-frame new-frame)
   (split-window)
   (select-frame old-frame)
   (one-window-p nil new-frame))

gets me nil as expected.

 > Note: I have this comment in the code just before the call to `one-window-p'.  I
 > do not recall the issue, but the comment has been there for quite a while:
 >
 > ;; We should be able to use just (one-window-p),
 > ;; but an Emacs bug means we need this:
 > (one-window-p nil 'selected-frame)))
 >
 > Does that ring a bell?

No.

 > Even if that bug has since been fixed, I will presumably
 > need to keep that, for older releases.  Just wondering if you recall anything
 > about that bug.

All I can say is that for me `one-window-p' is much too hard to
understand.  I wouldn't use it.  Can't you compare the results of
`frame-first-window' and `minibuffer-window' instead?

 >> You mean that `save-select[ed]-window' can redirect focus and not
 >> direct it back to where it was before calling it?
 >
 > That's certainly what it seems like.  And there is definitely a difference here
 > wrt what `save-window-excursion' does (that function DTRT here).  Perhaps this
 > info gives you a starting point for investigating.

Hardly.  Neither of these should affect focus.

 >> 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).
 >
 > Yes, AFAICT the behavior is the same in all Emacs versions.
 >
 > Do you have a suggestion for a simpler test?  If so, perhaps you can test it.

No idea.

 >>  > 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?
 >
 > I suppose so.  _Should_ that make a difference?

Apparently it does make a difference in your case.

 >> No.  Can't you distill a simple test case?  `redisplay' shouldn't care
 >> about frame focus either.
 >
 > You are saying the same thing I am.  Can you distill a simpler test case?

No.  All I can say is that manually selecting the `minibuffer-window'
seems harmful.

 > You seem to be saying that Emacs has introduced bugs, and nothing more.

Where did I say that?  IIUC all Emacs version behave the same wrt your
scenario.

 >  OK, so
 > I hear the admonition to avoid `select-window' wherever possible.  That's a
 > sorry state, though.  You seem to be saying that things that used to work, and
 > work simply, are now so bugged or complicated that all we can advise is to avoid
 > using `select-window'.

Selecting a window or a frame for the sole purpose to retrieve or
compare a value related to that window is plain overkill given that
`select-window' also selects a frame, makes a buffer current ...

 > I would like to know about `one-window-p', however.  Is the Emacs 24 doc string
 > wrong?  The code is identical to the code for Emacs 20.7, but suddenly we have a
 > very different behavior description.  Is the new description correct for Emacs
 > 24 plus older releases?  That would be good news (just an old-doc bug).  For the
 > moment, the situation is not clear.

I think it was a bug in the old doc-string.

martin