From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Date: Mon, 11 Jul 2022 17:15:08 +0000 Message-ID: References: <61fe102b-eec2-9711-560e-c141ed3cc6e4@gmx.at> <83fsj7zjkw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34881"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, 56305@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 11 19:16:32 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oAx1L-0008oP-8j for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Jul 2022 19:16:31 +0200 Original-Received: from localhost ([::1]:45358 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oAx1K-0002RZ-9K for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Jul 2022 13:16:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45432) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oAx0s-0002Np-I7 for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2022 13:16:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47000) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oAx0s-0001NH-4K for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2022 13:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oAx0s-0000kP-02 for bug-gnu-emacs@gnu.org; Mon, 11 Jul 2022 13:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Jul 2022 17:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56305 X-GNU-PR-Package: emacs Original-Received: via spool by 56305-submit@debbugs.gnu.org id=B56305.16575597182813 (code B ref 56305); Mon, 11 Jul 2022 17:16:01 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 11 Jul 2022 17:15:18 +0000 Original-Received: from localhost ([127.0.0.1]:40897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oAx09-0000jJ-Ju for submit@debbugs.gnu.org; Mon, 11 Jul 2022 13:15:17 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:62892 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1oAx07-0000iy-Mv for 56305@debbugs.gnu.org; Mon, 11 Jul 2022 13:15:16 -0400 Original-Received: (qmail 23002 invoked by uid 3782); 11 Jul 2022 17:15:09 -0000 Original-Received: from acm.muc.de (p4fe15cf0.dip0.t-ipconnect.de [79.225.92.240]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 11 Jul 2022 19:15:08 +0200 Original-Received: (qmail 7792 invoked by uid 1000); 11 Jul 2022 17:15:08 -0000 Content-Disposition: inline In-Reply-To: <83fsj7zjkw.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:236706 Archived-At: Hello, Eli. On Mon, Jul 11, 2022 at 19:43:11 +0300, Eli Zaretskii wrote: > > Date: Mon, 11 Jul 2022 16:22:21 +0000 > > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > > 56305@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > 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 > > 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. I think we're in violent agreement here. > > > 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. 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? > > > 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. OK, but that doesn't really address the point I was trying to make. That is, that select-window (and other functions too) should have an unambiguous, clear function, which should be unambiguously documented. Whether select-window raises the frame or not (and you say here not), it should _always_ either do it or not do it. There shouldn't be a "sometimes" in the doc. It is these "sometimes"es which lead to bugs like the current one. > 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. OK, so maybe we could agree that select-window ought to move focus onto the target frame, but not raise it (modulo fascistic window managers). Then we'd probably want a separate function which does raise that frame. 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. -- Alan Mackenzie (Nuremberg, Germany).