bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  >  "Spawning child process: invalid argument
> 
> No idea.  Maybe this is the Powershell issue described in
> http://tb-nguyen.blogspot.co.at/2010/05/how-to-fix-emacs-windo
> ws-error-spawning.html
> 
> I just checked on a SP3 machine and am sure that just 
> installing SP3 is not sufficient for the problem to show up.

I do not have/use Powershell, AFAIK.  But I see that my env var SHELL has the
value "/bin/bash".  That is no doubt the cause.

>  >> I still don't understand the consequences described in the
>  >> doc-string of `redirect-frame-focus' as
>  >>
>  >>     A frame's focus redirection can be changed by `select-frame'.
>  >>     If frame FOO is selected, and then a different frame BAR is
>  >>     selected, any frames redirecting their focus to FOO 
>  >>     are shifted to redirect their focus to BAR.  This allows focus
>  >>     redirection to work properly when the user switches from one 
>  >>     frame to another using `select-window'.
>  >
>  > I think that last part means only that focus switches when 
>  > you select a frame, even if the previously selected frame
>  > was not really selected but had the focus
>  > only via a redirection from the actually selected frame.
> 
> It seems to say that when a frame X has focus redirected to 
> the selected frame A and I now select a frame B then focus
> for X is redirected to B.  But why is that useful?

The reason given is to pass redirection on, when you switch to another frame.
But I agree that it is not clear, and I too wonder about the usefulness.

I would think that redirection should be a simple mapping from one frame to
another.

Now maybe what was really meant is that if X redirects to Y and Y redirects to Z
then X ends up redirecting to Z.  That would make sense (and also go without
saying).  Dunno.

>  >>     This means that a frame whose focus is redirected to itself is
>  >>     treated differently from a frame whose focus is redirected to
>  >>     nil; the former is affected by `select-frame', while 
>  >>     the latter is not.
>  >
>  > It does not say what does affect the latter.  Not too clear to me.
> 
> It seems to say that when a selected frame A's focus is 
> redirected to A itself and I now select frame B, focus from A is
> redirected to B.

Yes, I think it says that.  And it says that a frame that is redirected to nil
is not affected by select-frame.  (It does not say what does affect a frame that
is redirected to nil.)

> Now suppose a minibuffer-only frame is selected and had focus directed to
> itself. If now a minibuffer-less frame gets selected, focus will be
> directed to that frame which hardly makes sense to me.

I agree.  But why would someone redirect the minibuffer frame's focus to itself?
What are you envisioning?

FWIW, the only redirection that I use (AFAIK) is to redirect my *Completions*
(special-display) frame to the minibuffer frame.  That seems to work just as I
would expect - no problems.

But nothing prevents you from explicitly selecting *Completions* and even trying
to type input there, even when the minibuffer is active.  But *Completions* is
read-only, so if you do that you get a read-only error.

For example, in the minibuffer, Icicle mode binds `C-insert' to a command that
does (select-window (get-buffer-window "*Completions*" 0)).  You can do various
things there, but if you try to type a self-inserting char or delete a char then
you get this error: "Buffer is read-only: #<buffer *Completions*>".

> Someone (maybe Jan) once said that it's hard to override any such
> decisions when they are made by the window manager.

I did not mean override (prevent/nullify).  I meant automatically take remedial
action after the window manager's autofocus takes effect.  I.e., automatically
move the focus back where it was.

But again, I have no idea whether (a) that is easy to do or (b) whether it is
really a good idea to do it.

> IIUC creating a WM window (via CreateWindow) returns a handle to a new
> WM window independently from whether that window already 
> appears on the screen and/or obscures other windows.
>
> I don't know whether and how the window manager informs Emacs
> that a window has appeared on the screen.  I suppose it doesn't
> and that information is passed to emacs implicitly
> when the user "selects" that window by using the keyboard or 
> the mouse.

How does Emacs determine the selected frame?  Doesn't the code of
`selected-frame' help understand this?

>  >> and hope that read_minibuf correctly redirects the prompt 
>  >> to the minibuffer frame.
>  >
>  > My guess is that it does, always.
> 
> Apparently not always as we know meanwhile.

I did not really mean "redirects the prompt".  I was thinking of it moving the
input focus (which would also put the prompt where that focus is, presumably).

My guess was/is that it might always move the focus to the minibuffer frame, but
that the focus is then moved away from it to the new frame that is popped up.

How do you know that that is not what happens?  I.e., how do you know that there
are some situations where the focus is *not* (initially) switched to the
minibuffer frame?  (I'm not saying you are wrong - just wondering how you know
that.) 

>  > Again, my guess is that it did that
>  > correctly, but the new frame was then created (the 
>  > creation might have started before the read_minibuf, but the
>  > new focus took effect after the redirection to
>  > the minibuffer, in any case).  Just a guess.
> 
> From what you said it seems to work as long as no new frames are
> created.  When a new frame is created, it may take some time for this
> mechanism to adapt itself to the new configuration.

Perhaps, but waiting does not help.  Perhaps you meant that there is some
timeout and if things are too slow then the focus is automatically moved to the
new frame?