bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Mon, Jul 11, 2022 at 13:34:55 -0400, Stefan Monnier wrote:
> > Perhaps that "sometimes" could be expanded upon.  How is the Lisp hacker
> > supposed to know when she's got to raise or focus the frame in addition
> > to selecting a window?

> I think we need to distinguish the WM-level notion of focus from an
> "Emacs-internal" notion of focus.

> >From that point of view, WM-focus and raising should be changed (from
> ELisp) only in fairly rare circumstances.

Like C-x 5 o, you mean?  ;-)

> > OK, so maybe we could agree that select-window ought to move focus onto
> > the target frame,

Or, on the other hand, maybe not.

> Hmm... maybe in some cases, but probably not when Emacs doesn't have focus.

> > but not raise it (modulo fascistic window managers).

> Indeed.

> > My larger point is that all these functionalities, focussing, raising,
> > selecting, "highlighting", whatever, seem to be mixed together in the
> > code.  If we could separate them into coherent functions, we would have
> > fewer bugs like the current one in the future.

> In theory we do separate them, with things like
> select-frame-set-input-focus/x-focus-frame/raise-frame on one side and
> select-frame/window on the other.

I'm talking more about the practice than the theory.  This bug happened
when a select-frame grabbed the focus for the wrong frame.  select-frame
isn't meant to do that.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).