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

[martin rudalics]

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