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: Fri, 8 Jul 2022 10:55:07 +0000 Message-ID: References: <83h73w8f7i.fsf@gnu.org> <83zghn7ckd.fsf@gnu.org> <83zghm5evt.fsf@gnu.org> <5d86d890-9a2e-e4d6-13fb-da03285ea003@gmx.at> 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="18984"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56305@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca, acm@muc.de To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 08 13:16:26 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 1o9lyC-0004oN-R4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Jul 2022 13:16:24 +0200 Original-Received: from localhost ([::1]:58906 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o9lyB-0003NS-P6 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Jul 2022 07:16:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56970) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o9leV-00019Z-0s for bug-gnu-emacs@gnu.org; Fri, 08 Jul 2022 06:56:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36839) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o9leU-0002KV-OQ for bug-gnu-emacs@gnu.org; Fri, 08 Jul 2022 06:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o9leU-0000ZW-JE for bug-gnu-emacs@gnu.org; Fri, 08 Jul 2022 06:56: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: Fri, 08 Jul 2022 10:56:02 +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.16572777182103 (code B ref 56305); Fri, 08 Jul 2022 10:56:02 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 8 Jul 2022 10:55:18 +0000 Original-Received: from localhost ([127.0.0.1]:58969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9ldl-0000Xr-KO for submit@debbugs.gnu.org; Fri, 08 Jul 2022 06:55:17 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:47062 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1o9ldj-0000XF-2z for 56305@debbugs.gnu.org; Fri, 08 Jul 2022 06:55:17 -0400 Original-Received: (qmail 46936 invoked by uid 3782); 8 Jul 2022 10:55:08 -0000 Original-Received: from acm.muc.de (p4fe15b6e.dip0.t-ipconnect.de [79.225.91.110]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 08 Jul 2022 12:55:08 +0200 Original-Received: (qmail 4559 invoked by uid 1000); 8 Jul 2022 10:55:07 -0000 Content-Disposition: inline In-Reply-To: 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:236446 Archived-At: Hello, Martin. On Fri, Jul 08, 2022 at 09:01:43 +0200, martin rudalics wrote: > > I don't follow. If the WM does "Raise on focus", surely it will > > raise the frame no matter how it acquires the focus. Such focus is > > here essential for the working of the minibuffer. > It should not deliberately raise a frame that already has focus. OK. We could add an extra check for the frame already having the focus. Is there anything else suboptimal about that proposed fix to emacs-28? > > Is it not the case that acquiring the focus with Fx_focus_frame > > would be better than not doing so? > It does not restore the Emacs 26 behavior. If you look at the reports > for Bug#8856, Bug#11566 or Bug#11939, you might be able to imagine how > much time I spent to get the behavior right for Drew's setup back then. > It's quite sobering to see my efforts from that period get wasted now. If there are bugs, we fix them. You're surely not saying that the Emacs 26 behaviour was ideal, are you? I'll take a look at these bug reports this evening. Part of the problem is that this desired behaviour is not formulated anywhere, and there don't appear to be tests in 'make check' for it. In the mean time, how well does the change to master work? It attempts to fix the cause of (rather than just working around) bug #56305. > >> AFAICT the most simple approach appears to restore the Emacs 26 > >> behavior for sessions with separate minibuffer frames. > > I'm not sure how simple that would be. Have you a patch to propose? > No. I think you should trace all 'minibuffer-follows-selected-frame' > related changes and make them pertinent to the value of that variable. > Then people who need the old behavior could get it back by setting that > variable to nil. That would be an enormous amount of work, since the code was to a significant extent in a chaotic state when I made those changes. I think it is now in a less chaotic state. We surely do not wish to restore the chaos. Even If I were to do that, I doubt Eli would accept the result for Emacs 28.2, since it would be too large a change. Again, how well does my change made last night to master fix the bug? As a matter of interest, the setting of minibuffer-follows-selected-frame which gives behaviour closest to the old is non-nil, non-t (e.g. the symbole `hybrid'). > It was an unwritten rule of Emacs development that a new feature that > breaks established behavior should be (a) made optional and (b) by > default turned off. Maybe that rule doesn't apply any more but at > least (a) should be still supported. > >> What would the semantics of 'minibuffer-follows-selected-frame' be for > >> such a session anyway? > > I've a vague memory of checking this was OK at the time of the change. > > I can't remember many of the details now, though. > Then please try to remember. AFAICT 'minibuffer-follows-selected-frame' > should never impact the behavior of separate minibuffer frames. Again, bug #56305 was not caused by the m-f-s-f changes, but by some chaotic code in do_switch_frame which is hopefully now fixed (in master). I don't agree with you that reverting the minibuffer-follows-select-frame changes is a good way to fix the current bug, or any similar bugs. If my last night's commit to master is satisfactory, perhaps it might somehow be possibly to cherry-pick it into Emacs 28.2. > martin -- Alan Mackenzie (Nuremberg, Germany).