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#48674: Frames and minibuffer bug Date: Sat, 29 May 2021 13:10:09 +0000 Message-ID: References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@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="19305"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48674@debbugs.gnu.org, Iris =?UTF-8?Q?Garc=C3=ADa?= To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 29 15:11:13 2021 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 1lmykA-0004ph-9R for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 May 2021 15:11:10 +0200 Original-Received: from localhost ([::1]:34654 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmyk9-0007sa-As for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 May 2021 09:11:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmyk2-0007sJ-5v for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 09:11:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44739) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmyk1-0004D4-Ow for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 09:11:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lmyk1-0003mu-JY for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 09:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 May 2021 13:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48674 X-GNU-PR-Package: emacs Original-Received: via spool by 48674-submit@debbugs.gnu.org id=B48674.162229382014511 (code B ref 48674); Sat, 29 May 2021 13:11:01 +0000 Original-Received: (at 48674) by debbugs.gnu.org; 29 May 2021 13:10:20 +0000 Original-Received: from localhost ([127.0.0.1]:56285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmyjM-0003lz-4O for submit@debbugs.gnu.org; Sat, 29 May 2021 09:10:20 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:20438 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lmyjI-0003ld-Au for 48674@debbugs.gnu.org; Sat, 29 May 2021 09:10:18 -0400 Original-Received: (qmail 42628 invoked by uid 3782); 29 May 2021 13:10:09 -0000 Original-Received: from acm.muc.de (p2e5d5176.dip0.t-ipconnect.de [46.93.81.118]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 May 2021 15:10:09 +0200 Original-Received: (qmail 697 invoked by uid 1000); 29 May 2021 13:10:09 -0000 Content-Disposition: inline In-Reply-To: <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at> 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:207531 Archived-At: Hello, Martin. On Sat, May 29, 2021 at 11:20:58 +0200, martin rudalics wrote: > > I think the following patch, along the above lines, solves the bug > > completely. Could you review it for me, please? Thanks for the review. I withdraw my assertion about a complete solution to the bug. :-( > It fixes the bug and the potential use case I mentioned earlier. But > for this part > /* If the new frame's selected window is the mini-window, select > some other window if we don't have an active minibuffer there. */ > if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (f))) > && !live_minibuffer_p (XWINDOW (FRAME_SELECTED_WINDOW (f))->contents)) > Fselect_window (Fframe_first_window (selected_frame), Qnil); > I would first have to understand why such a minibuffer window should be > OT1H its frame's selected window and OTOH not be active when switching > back to that frame. When the user switches from F1 to F2 with C-x 5 o, and there was an active minibuffer on F1, that MB gets moved to F2. The user then terminnates the MB....then switches back to F1. There is no longer an active MB. > As a user I can always do > (select-window (minibuffer-window)) > regardless of whether a minibuffer is active. Switching away from that > window's frame and back to it is problematic in Emacs 27 - no window has > the active cursor. You apparently fixed this by selecting the frame's > first window when switching back. Right? Yes. > One reason why I ask is because with emacs -Q and the present patch > (setq default-frame-alist '((minibuffer . nil))) > followed by C-x 5 2 and > (select-window (minibuffer-window)) > in the new frame violates the assertion on line 548 of window.c > /* Fselect_frame called us back so we've done all the work already. */ > eassert (EQ (window, selected_window)); > with the backtrace below. Just as a quick aside, how do I configure Emacs so as to generate these easserts? At the moment I've got CFLAGS='-O0 -g3' and --enable-checking in my ./configure command line. I think I'm missing something. > Basically, I would try to avoid that a non-selected frame's selected > window is an inactive minibuffer window. But I'm not sure how difficult > it is to achieve that. That's the way it currently is (without the patch). It is difficult to make it work properly. Maybe the best workaround would be to create a new flag in struct frame, which when set means "select mini-window if "possible" when selecting this frame". "Possible" meaning there's an active MB. (i) This flag would be set, somehow, by with-selected-frame when moving away from F1. (ii) do_switch_frame would test this flag, act on it, and clear it. f->flag would always be clear when f is the selected frame. With this, F1's selected window would be moved away from the mini-window and the flag set, when F2 gets selected. Or something like that. What do you think? > martin [ Backtrace snipped, but understood. ] -- Alan Mackenzie (Nuremberg, Germany).