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: Tue, 5 Jul 2022 15:59:00 +0000 Message-ID: References: <3984f6ec-1988-f0ae-d44c-f4b92a202938@gmx.at> <83o7yb5lqe.fsf@gnu.org> <83bku69nn2.fsf@gnu.org> <83iloc8yzs.fsf@gnu.org> <83h73w8f7i.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="3425"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, 56305@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 05 18:01:42 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 1o8kze-0000gA-E6 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Jul 2022 18:01:42 +0200 Original-Received: from localhost ([::1]:41290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o8kzc-0004Fr-Lz for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Jul 2022 12:01:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o8ky3-00042v-F8 for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2022 12:00:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57467) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o8ky3-0002zc-2V for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2022 12:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o8ky2-0000lh-Sg for bug-gnu-emacs@gnu.org; Tue, 05 Jul 2022 12:00: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: Tue, 05 Jul 2022 16:00: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.16570367632876 (code B ref 56305); Tue, 05 Jul 2022 16:00:02 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 5 Jul 2022 15:59:23 +0000 Original-Received: from localhost ([127.0.0.1]:51364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o8kxF-0000k9-1B for submit@debbugs.gnu.org; Tue, 05 Jul 2022 11:59:23 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:49986 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1o8kxA-0000js-KF for 56305@debbugs.gnu.org; Tue, 05 Jul 2022 11:59:11 -0400 Original-Received: (qmail 72385 invoked by uid 3782); 5 Jul 2022 15:59:02 -0000 Original-Received: from acm.muc.de (p4fe15b7e.dip0.t-ipconnect.de [79.225.91.126]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 05 Jul 2022 17:59:01 +0200 Original-Received: (qmail 7725 invoked by uid 1000); 5 Jul 2022 15:59:00 -0000 Content-Disposition: inline In-Reply-To: <83h73w8f7i.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:236133 Archived-At: Hello, Eli. On Tue, Jul 05, 2022 at 05:29:21 +0300, Eli Zaretskii wrote: > > Date: Mon, 4 Jul 2022 19:43:51 +0000 > > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org > > From: Alan Mackenzie > > > > Quick summary of the problem: On an Emacs with a minibuffer-only frame > > > > (MBF) and a minibuffer-less frame (NF), with MBF selected with focus, > > > > type C-x C-c. Instead of the focus remaining in MBF, it's moved to NF. > > > I lost you right here: can you explain why what you described isn't > > > TRT? > > After typing C-x C-c, rather than exiting, this particular Emacs > > prompts: > > "Active processes exist; kill them and exit anyway? (yes or no) " > > on MBF and it opens a window *Process List* on NF. > Sounds right to me: the frame where Emacs presents some important > information has focus. If you think this is wrong, please tell why. Well, I don't have a firm opinion on this, but yes-or-no-p is an active function, here. We always leave the minibuffer as the selected window for this function, certainly when we've a normal minibuffer in the frame. Why should it be different when we've got a minibuffer-only frame? Also, the mechanism by which NF gets the focus in the bug scenario appears to be random. When the focus starts out in NF and we do C-x C-c, the focus moves to MBF. This is inconsistent. The place where the randomness takes effect is the Fredirect_frame_focus (gfocus, frame); in do_switch_frame I drew attention to yesterday. > > > I mean, after you typed "C-x C-c", the minibuffer (whether it's a > > > frame or a window) has completed its job, and focus should return to > > > the "real" frame, which is NF. Right? What am I missing here? > > After the C-x C-c, and the appearence of the prompt, NF has the focus, > > uselessly, instead of MBF. > How is Emacs supposed to know that the user wants only to _look_ at > the list of processes in this case? In general, moving focus to where > the information is sounds right to me. See above. > > That means having to do a window-manager > > action to get at the prompt. This is the bug that Martin registered. > In the scenario you described, I'm not sure it's a bug. In general, > when Emacs prompts with a question in the minibuffer frame and > displays some information pertaining to the question in another frame, > it is not completely clear where should the focus be. E.g., suppose > that the list of processes was so long that it wouldn't fit in one > window-full, and you'd need to scroll it to see all of it -- wouldn't > you want then to have the focus in the frame with the process list? You might, yes. But I think the irritation in having to switch frames to NF to look at the long list will be outweighed by the opposite irritation of always having to switch frames to MBF to answer "yes" or "no". -- Alan Mackenzie (Nuremberg, Germany).