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

[Drew Adams]

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

Is that sure to DTRT?  If so, fine.  I am not familiar with
`frame-first-window'.  It was certainly not obvious to me that if those two are
eq then the frame can only be showing a minibuffer window (no other windows).

`f-f-w' is written in C, and its definition has changed somewhat over Emacs
releases.   But if I pass a frame parameter then I guess the different
definitions should amount to the same thing.  I'll give that a try.

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

What can I say?  `save-selected-window' sure seems to.

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

Too bad.

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

FWIW, I have not encountered any bugs selecting it (whatever you might mean by
"manually"), aside from the `save-selected-window' bug reported here.

>  > You seem to be saying that Emacs has introduced bugs, and 
>  > nothing more.
> 
> Where did I say that?

In the text you snipped, just before that sentence of mine:

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

And by "nothing more" I meant no more explanation: your "I can't explain any of
these".

> IIUC all Emacs version behave the same wrt your
> scenario.

Correct.  It is you who suggested that selecting a window used to be simpler
than now, and that now it has "many" side effects - so much so that you advise
people to avoid `select-window'.  My finding was that the `save-selected-window'
changes-the-focus bug is present in all Emacs releases (20 through 24).

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

Agreed 100%.  That's why I welcome your suggestions of simpler code to
accomplish that.

It was not obvious to me that `frame-first-window' could be used to test for
only-one-window-ness, or that the doc prior to Emacs 24 for `one-window-p' was
not correct wrt a frame argument.  Your simplifications are welcome, but they
were far from obvious, to me.