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

[martin rudalics]

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