Re: C-x o is moving between frames. [Was: Stop frames stealing eachothers' minibuffers!]

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Oct 24, 2020 at 10:26:55 +0300, Eli Zaretskii wrote:
> > Date: Fri, 23 Oct 2020 20:42:57 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > 
> > They almost take care of themselves.  Almost, but not quite.  I've had a
> > closer look at minibuffer-only frames, and it feels like I'm opening
> > Pandora's box[*].  Even in the unchanged master branch, I get this:

> Of course, you've opened a Pandora box! what else did you expect doing
> changes in this area?

Fair enough!  All I can say at the moment is that my patch, although
seemingly working with "ordinary" frames, was incomplete with respect to
minibuffer-less frames.  It's going to take me longer to make it
complete, possibly a lot longer.  :-(

> The documentation of next-window, which is the function that selects
> the "other" window, says:

>   ALL-FRAMES nil or omitted means consider all windows on WINDOW’s frame,
>   plus the minibuffer window if specified by the MINIBUF argument.  If the
>   minibuffer counts, consider all windows on all frames that share that
>   minibuffer too.

> So this is very old and intended behavior.  If you want to change that
> as well, you will need more changes.

No, I don't want to change that.  I'm just trying to understand how it
works.

At the moment, when I create a setup with three frames, exactly one of
which is a "normal" frame with minibuffer, my C-x o can be made wrongly
to cycle between all three frames.  It is bugs like this I must fix, and
my feeling at the moment is that there will be more than just that one.
:-(

So, please disregard my optimistic patch, and I'll carry on working on
the MB-less frame cases.

-- 
Alan Mackenzie (Nuremberg, Germany).