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

[Stefan Monnier]

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

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

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.


        Stefan