bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
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@gnu.org>, monnier@iro.umontreal.ca,
>   56305@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]