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 14:08, martin rudalics <rudalics@gmx.at> wrote:
>>> With "activated window at the window-manager level" you mean the window
>>> that has input focus and has its title bar painted differently from
>>> other windows but is not necessarily the topmost window in the Z-order?
>>> That window is here the one showing frame 1 after you switched to it via
>>> C-x o.
>>
>> It's the one showing frame 2, as I said.
>
> So we seem to have another problem.  Just to make sure, I use a mingw32
> build of Emacs 25 on Windos XP with the following patch
>
> --- a/src/frame.c
> +++ b/src/frame.c
> @@ -1157,7 +1157,10 @@ do_switch_frame (Lisp_Object frame, int track, int
> for_deletion, Lisp_Object nor
>        if (FRAMEP (xfocus))
>         {
>           focus = FRAME_FOCUS_FRAME (XFRAME (xfocus));
> -         if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
> +         if ((FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
> +             || (NILP (focus)
> +                 && EQ (FRAME_MINIBUF_WINDOW (XFRAME (frame)),
> +                        sf->selected_window)))
>             Fredirect_frame_focus (xfocus, frame);
>         }
>      }

Ah. I'm on the master branch (using a mingw64 build on Windows 10,
with the same patch).
emacs-repository-version is e1c5422e7bc2fbe0ecf5ab501b39d32fac61e747.

(Time passes ...) I do see exactly the same on the emacs-25 branch
as I see on the master branch.
emacs-repository-version is f1247f069e6a908595748c315948c636962b60dc.

> Now with emacs -Q I put the following form
>
> (make-frame '((minibuffer . nil)))
>
> in *scratch* and evaluate it via C-x C-e.  This gets me a new frame, say
> F2 which is selected and has input focus.  To avoid confusion I make the
> sole window in F2 show *Messages*.
>
> Now I do C-x 5 o which gets me back to the initial frame, say F1.  F1 is
> selected and has input focus.  Now I do M-x.  F1 is still selected and
> has input focus.  Now I do C-x 5 o.  F2 gets selected and has input
> focus.  Can we agree until here?

Yes, agreed. And what's more, until here the window manager's window
activation (as evidenced by the text style in the title bar) has followed
the selected frame.

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

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.

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

>> * if I type C-x 5 o the activated window does change.
>>
>> Is that the visible difference you mean?
>
> It's not in your original scenario but apparently our installations
> differ here.  Are you sure you applied the same change as I did?

I applied the same change as you did.

>>> But what's wrong with that?  After all you _did_ use C-x o to select
>>> that window.
>>
>> It's not wrong until you type Alt-Tab.
>
> Alt-tabbing was not part of your scenarios so far.  Please give a
> step-by-step recipe indicating the first time it fails.

OK, but as a matter of fact, I was talking about Alt-Tab in the original
recipe in message #23, and I clarified that in message #29. Sorry if
I haven't been making myself clear. I think the video has helped.

>>> Do you mean that on frame 1 you cannot use Alt-Tab to switch to frame 2?
>>
>> Possibly.
>>
>> Typing Alt-Tab several times switches the window-manager's activation
>> between frame 1 and frame 2 (and other windows that may be present
>> if you hold Alt and type Tab more than once). I can switch activation
>> between
>> the two Emacs windows and any other windows as much as I like, as
>> evidenced by the title-bar painting style.
>>
>> But no amount of typing Alt-Tab changes which Emacs window contains
>> the solid flashing cursor where text is inserted when I type characters.
>
> Here Alt-Tab always switches between all Emacs frames.  Otherwise we
> would have had problems on any multi-frame layed-out Emacs.  And
> certainly we would have had problems in an unpatched Emacs when invoking
> M-x from the minibuffer-less frame.  Can you try if C-x o fails for that
> 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.

>> Firstly, no, I'm in frame 2.
>
> 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.

>> Secondly, I'm saying that any amount of switching between windows,
>> either using Alt-Tab, or by clicking on title bars, makes no difference
>> to the window where text is inserted.
>
> Can anyone observe that?  I just tried on Windows 7 and see the same
> behavior as on XP.
>
>>> Here at any moment I can use Alt-Tab or the mouse to select any of the
>>> three windows involved in your scenario and continue typing text there.
>>> If this doesn't work on your system please tell me precisely where it
>>> fails.
>>
>> I have tried to do that.
>
> I'm left without clues.

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

> martin