bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present

[martin rudalics <rudalics@gmx.at>]

 >> Now I do C-x o.  This selects F1 and gives it input focus with the
 >> *scratch* window selected.  Typed text appears in *scratch*.  If F1 and
 >> F2 overlap, F2 obscures F1.  I suppose you observe something different
 >> here.
 >
 > In this terminology, does "selects F1 and gives it input focus" imply
 > that the F1 becomes the active window (in other words, that its title
 > bar is painted active)?

Hmmm... I could have sworn it did so.  But it doesn't.

So the answer is (until further notice): The frame where I typed M-x
into is the one whose title bar is painted active throughout the
subsequent C-x o sequence.

 > If "Yes" then yes, I observe something different, that the window
 > does not get activated (i.e., its title bar text remains grey).
 >
 > If "No" then no, I observe all of that, and I also observe that the
 > window does not get activated.

It's "No" actually, but maybe I didn't pay enough attention to that
earlier.  Anyway: Typed text always applis to the window selected via
C-x o.  Can you confirm that?

 >>   Now I do C-x o again.  This selects the minibuffer window on F1.
 >> Typed text now appears in the echo area.
 >
 > Agreed.
 >
 >>> Here, after typing M-x in *scratch* in the recipe:
 >>> * if I type C-x o the activated window does not change;
 >>
 >> You mean C-x o does not take you to F2 in my parlance.  Here F2 gets
 >> selected and input focus.
 >
 > I'm not sure what you mean. In my case F2 becomes the selected frame
 > in the sense of (selected-frame), and typed text goes to the selected window
 > of frame F2 (it goes to *scratch*), and F1 remains the active window (the
 > one with black title bar text).

OK.  It seems that after all we do see the same behavior with respect to
C-x o and C-x 5 o.

 > In an unpatched emacs (on master, the emacs from my original report,
 > emacs-repository-version 7fa96cb5ef8c8464496688e88c1b97211a820d79),
 > C-x o doesn't fail. It can cycle through all three windows more than once.
 > The title bar activation doesn't follow the input focus; the minibuffer-less
 > frame's title bar remains activated throughout the M-x C-x o C-x o ...
 > sequence (I'm not saying that's wrong, I'm just saying that's what happens).
 > Doing C-g in the minibuffer correctly returns the input focus to the
 > minibuffer-less frame.

But then the "title bar activation doesn't follow the input focus"
behavior is just the same, regardless of whether you issue the M-x in
the minibuffer-equipped or in the minibuffer-less frame.  Can we agree
that the frame where we issue the M-x keeps the title bar activated for
the entire C-x o sequence until we either type C-x 5 o or C-g in the
minibuffer?

 >> So you mean that frame 2 has input focus and is selected and clicking on
 >> frame 1 does not select frame 1 and give it input focus?  Something must
 >> be broken on your side.
 >
 > Yes, apparently.

I'd still want to see comments from other Windows users on this.  Can
you provide a scenario people can test on an unpatched emacs -Q where

(make-frame '((minibuffer . nil)))

followed by M-x in the new frame doesn't allow switching frames via
Alt-Tab or mouse clicks as long as the minibuffer is active?  We need a
third opinion on this.

 > Just a thought: do you use focus-follows-mouse? I don't.

You mean the Emacs option?  Normally I do use it but not with emacs -Q.
I configured Windows with XMouse support such that hovering the mouse
over a window will give it focus and raise it - but this can hardly be
more powerful than clicking into a window.

[In fact, as I just noticed, it isn't.  During focus redirection, I can
confuse Windows by typing C-x o with the consequence that now the frame
I move the cursor to gets the active titlebar but blinking cursor and
input focus remain on the frame where the mouse movement started.  Only
as soon as I mouse-click into a frame, moving the cursor to the other
frame makes the behavior congruent again - that is blinking cursor and
input focus again move with the active titlebar.]

And Alt-Tabbing should not be affected by this setting anyway.  Well,
Redmond occasionally had troubles with the Alt-Tab code ...

martin