GNU bug report logs - #56305
29.0.50; 'yes-or-no-p' deselects minibuffer frame

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: rudalics <at> gmx.at, 56305 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, acm <at> muc.de
Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
Date: Mon, 11 Jul 2022 19:43:11 +0300

> Date: Mon, 11 Jul 2022 16:22:21 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca,
>   56305 <at> debbugs.gnu.org, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > So you implemented 'minibuffer-follows-selected-frame' despite the fact
> > that multiple frames hardly make sense on your usual setup?
> 
> That's not a fact.  I typically run with several/many frames on my tty.
> Six, or even nine, is not uncommon.  I switch between them using the
> <Fn> keys.  The minibuffer not staying in "its own" frame was annoying
> me quite a bit.

I hope you'll agree that focus redirection is not very relevant to TTY
frames.  There, the top-most frame is the only one visible, and by
definition it has the focus.

> >    Note that sometimes selecting a window is not enough to show it, or
> >    make its frame the top-most frame on display: you may also need to
> >    raise the frame or make sure input focus is directed to that frame.
> 
> That sounds like the text from a bug report.  Selecting a window should
> either do all these GUI things, or it shouldn't do them.  "Sometimes"
> feels like an apology for failing to fix a bug before a release.

Please don't forget that Emacs is not entirely in control of what
happens here: the window manager is also an important part of this
dance, and it has its own ideas about which frame should be raised and
which should be given focus.  It is unreasonable to expect Emacs to be
able to work around every idiosyncratic aspect of the behavior of
every window manager, let alone customized by users.

> > wouldn't make sense if in a majority of cases selecting a window would
> > _not_ also raise its frame and direct input focus to it.
> 
> So why can't we make select-window _always_ raise its frame and get
> input focus?

Because it's wrong!  If I want to type into a window, it does NOT mean
I want that window's frame raise!  Imagine a situation where I look at
some text in one frame and type something into another frame: I can
legitimately want to see all of the text I'm reading, but only a small
portion of the text into which I'm writing.  Automatically raising a
frame in this case would be an annoyance, since each time I move the
focus into the "typing" frame, it would raise and obscure my "reading"
frame.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.