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 17:00:04 +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> <3dba4122-30e3-99a7-2326-263f3f7023cf@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="2408"; 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 19:01:29 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 1ln2L3-0000X7-5r for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 May 2021 19:01:29 +0200 Original-Received: from localhost ([::1]:43208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln2L2-0003bZ-87 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 May 2021 13:01:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48208) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ln2Kc-0003Z0-AL for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 13:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46087) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ln2Kc-0005aK-1x for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 13:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ln2Kc-0001Kh-0P for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 13:01: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: Sat, 29 May 2021 17:01: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.16223076165053 (code B ref 48674); Sat, 29 May 2021 17:01:01 +0000 Original-Received: (at 48674) by debbugs.gnu.org; 29 May 2021 17:00:16 +0000 Original-Received: from localhost ([127.0.0.1]:57633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ln2Js-0001JR-B8 for submit@debbugs.gnu.org; Sat, 29 May 2021 13:00:16 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:26451 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1ln2Jo-0001I9-Dl for 48674@debbugs.gnu.org; Sat, 29 May 2021 13:00:14 -0400 Original-Received: (qmail 25269 invoked by uid 3782); 29 May 2021 17:00:05 -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 19:00:05 +0200 Original-Received: (qmail 10790 invoked by uid 1000); 29 May 2021 17:00:04 -0000 Content-Disposition: inline In-Reply-To: <3dba4122-30e3-99a7-2326-263f3f7023cf@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:207545 Archived-At: Hello, Martin. On Sat, May 29, 2021 at 17:12:58 +0200, martin rudalics wrote: > > 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. > This is safe but not quite right. The last window on that frame > selected before the minibuffer window got selected should be selected > instead - that's the window returned by `minibuffer-selected-window' > immediately after selecting the minibuffer window. We'd probably have > to put that into the frame structure to make it work but this can wait. I agree, this can wait. ;-) > >> 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 > I use > --enable-checking='yes,glyphs' --enable-check-lisp-object-type=yes > but cannot tell which ones are right, which matter and from where I > obtained them. Thanks. It was just me being a bit stupid. I had minibuffer-follows-selected-frame set to nil, so I didn't get to the code which easserts. On setting that variable to t, I did get it. [ .... ] > > 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. > I doubt that anyone knows when we move away from a frame. With > emacs -Q --eval "(setq default-frame-alist '((minibuffer)))" > do in the normal, non-minibuffer frame > (select-window (minibuffer-window)) > You will see that the previous window remains selected but its mode line > changes to inactive. So even the display engine doesn't know which > frame is selected here. Maybe on purpose ... I've been thinking about my proposed mechanism. There is no need for with-selected-frame to set that new flag in struct frame. More simply, do_switch_frame can set it whenever the old frame has the mini-window selected. In the new frame it will check the flag and if appropriate select the MW. Functions such as Fselect_window and Fset_frame_selected_window which want to select a specific window would clear the flag. This mechanism could be implemented entirely in the C code, without affecting any Lisp interfaces. > > (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. > do_switch_frame is called by (i) and (ii) - so how would you "set" this > flag in (i) and "test this flag and act on it" in (ii)? How would > do_switch_frame distinguish between (i) and (ii)? Sorry, I think I was a bit unclear. The flag would be in struct frame, so (i) and (ii) would be acting on the flags for different frames. > OTOH what would go wrong if we did always auto-select a minibuffer > window in do_switch_frame when it is its `frame-selected-window' and > `minibuffer-depth' is non-zero regardless of whether the window's > minibuffer is on live_minibuffer_p or not? If it is not, then this > frame would just become the next participant in moving the minibuffer > from one frame to another. I don't think that situation can arise. We're talking exclusively about the (eq minibuffer-follows-selected-frame t) case, and in this case there will always be a live minibuffer moved onto the target frame when minibuffer-depth is non-zero. I think I'm going to discard yesterday's attempted patch, and write another patch along the lines sketched above. This will likely take me longer than just this evening. > martin -- Alan Mackenzie (Nuremberg, Germany).