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

[Alan Mackenzie]

Hello, Stefan.

On Sat, Oct 24, 2020 at 14:40:52 -0400, Stefan Monnier wrote:
> > 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.

> Depending on what you need to do before this can happen, I wouldn't
> necessarily worry about this particular issue too much because "the
> right behavior" is very hard (if not impossible) to define precisely in
> such a way that it makes sense in all cases.

I've found the cause of it.  It's some arcane coding in
candidate_window_p in window.c.  It's trying to move from an active
minibuffer to a (window in a) frame in which it's active, but fails to
check that the frame's MB is the MB we're moving from.  Or something like
that.  When I add that check, it behaves better. 

> FWIW, I still haven't found anyone using a setup like the one
> you describe.

I can't imagine anybody wanting to use it, either.  But if there are bugs
associated with applying my "minibuffer follows selected frame" patch,
they might bite in other circumstances.

> The ones I know are:

> - one minibuffer-only frame and all other frames a minibuffer-less;
>   At least "per terminal": there can also be at the same time a normal
>   tty frame (with minibuffer and all), or a second X11 display with its
>   own minibuffer-only frame, ...
> - all normal frames, except potentially a few very special minibuffer-less
>   frames used for very special purposes (behaving more like things like
>   tooltips, or tool bars or ...).

Yes.  Either a user will want "normal" frames, or frames without MBs and
a single minibuffer frame.

> > It is bugs like this I must fix, and my feeling at the moment is that
> > there will be more than just that one.

> If you can reproduce the problem without your patch, then I hope you
> won't count it as a bug, otherwise it'll never end.

Yes, I can see that danger.  I won't raise any bug reports for this sort
of thing without first discussing it on emacs-devel.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).