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

[Richard Copley <rcopley@gmail.com>]

On 1 October 2016 at 19:50, martin rudalics <rudalics@gmx.at> wrote:
>>> 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?

Yes.

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

Right. And the behaviour towards the end of the video, where clicking on
the title bars doesn't affect the window where typed characters are inserted:
do you see the same thing there as well?

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

Yes.

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

No, I haven't noticed such a scenario.

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

OK. I was wondering if some setting or third-party tool could explain the
differences between what you and I were seeing, but if there is no difference
after all (?) then it's not worth thinking about.

> martin