From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#48674: Frames and minibuffer bug Date: Sat, 29 May 2021 17:12:58 +0200 Message-ID: <3dba4122-30e3-99a7-2326-263f3f7023cf@gmx.at> 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=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23621"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48674@debbugs.gnu.org, Iris =?UTF-8?Q?Garc=C3=ADa?= To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 29 17:14:10 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 1ln0fB-00060c-So for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 May 2021 17:14:09 +0200 Original-Received: from localhost ([::1]:39250 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln0fA-0005FT-Uq for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 May 2021 11:14:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59068) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ln0f4-0005EO-EF for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 11:14:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46008) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ln0f4-0005MY-6y for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 11:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ln0f4-00079t-1S for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 11:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 May 2021 15:14: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.162230119127431 (code B ref 48674); Sat, 29 May 2021 15:14:01 +0000 Original-Received: (at 48674) by debbugs.gnu.org; 29 May 2021 15:13:11 +0000 Original-Received: from localhost ([127.0.0.1]:57552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ln0eE-00078N-Qk for submit@debbugs.gnu.org; Sat, 29 May 2021 11:13:11 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:53741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ln0eB-00077p-0G for 48674@debbugs.gnu.org; Sat, 29 May 2021 11:13:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622301179; bh=dp/BEeeF3+NEnqvdUP2zDA5ozDjoch5nU6RCXug8Buw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=gMUaVARd780yE21dh4Q//ZqFWzHi089CdjQHdZ30lyr6UW6Z0bvWgiHCfPrxrKxNa lij7G7ABFoqF65anIhYhWykOgadiSSZw3zovzRZ3eq+N+xKGo9oPX9c7774NTdOPuI acSTXZGKdpCQXfDZ0CXvsrD5AJHQm5jcbcUMXtIE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.7.233]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MrQJ5-1l1b3s0y3D-00oYCx; Sat, 29 May 2021 17:12:59 +0200 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:858OmK/YHc+55eNFXpqx8FklWkDcdIN/jLaK42+s7VFytbBSEha V16n1lb6P5YS0tA62Ad+0u5AZmZlvBnDbFskyE2V01q9Z7VDydo9xHRBpNrAW2mSpmIWgAd O+OI9R0qoiaFNToD6HyqyYvuaUrd4PYlA+/lATMlYk6YYfnRWm+3ssLtBtLjGpcEAHc/L9f e4JtGj21/J0rgDUbXSCJQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:QZcr3tkFGrM=:YysFBDwTazhDqdXZ0e8WIv c/Jnh9FKXlcWl2jBKy6aPVXz4+3dFUXugNlTbA+BnJofgVtqrfoMqNWws8EpEY29KRIsz3+pv D/iazAm1AvZHgdh96kWNuEPl6awUTTmsSy4pNCBj+G6sVaMQ6zjCbg7eBNvPBiRMQB1u8YLTn 7TDo9zkwEaWV0NyxWmlLJ+p+Y9pa1CqcWsb9LJUPOri4y4eKcJXlRSUfCFMlx6yFUcCHOooq5 UXQI5iJXPB/qr4RWnM3YPQMD+W3A7t/JFWdveUZKGerXByecEyV2wPFGNqmkQK1hFZ0ujFrvz 2swuivm9Ke80I+EJB/4vg7STO2MKa/9J3oaqLGecerSTXjXsh4WQLueJxSgXz0qzIrtW5hjzt b/aUyHFobDEHD3Fa3ZvDtdTV4p5PW7mc8FQRYFGlKMx76XeOBFoIpzxwMW/oqRPeOby/2A7Q6 XWCbOCVVpQtJqP655+KDCtdlZVb0KQ8xlWBh08oN5MDDmmjAuYUEzYwaU77bDZaJ2JTZOHQcy UcsXweaLJicBqrtS/zhIOO/sm1tFp6RBMTFCVDzVMGVsJGDWZpRqsUorLAgLlGMusC+FmXqBD vGKQK9dG5XAg1XinKwt89pi2usE84y/CCDsCkqtkIzX3I5ZG6ylVce3CBeypPzCD1s3dcVQjj 7QIrsvdswzSe49qmgSWGOUpzayMVdeSOWVH93JLQojJ2q+5u+Bmk+q0kJFMPAOdez2RBVuCG6 fZCLHV6g/PHtVlgJpJEuZW4iFCRCtzJzs0Uw9vpLrWRKftKHyOw8qw8RXqgBOrQ4pxjFSDib 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:207539 Archived-At: > 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. >> 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. > 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. 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 ... > (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)? 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. martin