GNU bug report logs -
#56305
29.0.50; 'yes-or-no-p' deselects minibuffer frame
Previous Next
Full log
Message #173 received at 56305 <at> debbugs.gnu.org (full text, mbox):
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).
This bug report was last modified 2 years and 331 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.