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#45792: 28.0.50; regression in commit c7c154bb, minibuffer is not closed after opening a file Date: Sun, 31 Jan 2021 17:01:40 +0000 Message-ID: References: <75aca8c3-6c8f-2a66-399e-7116d99c91d3@gmail.com> <81a72c8d-b92c-2eea-5ef3-ec4988634095@gmail.com> 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="24756"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45792@debbugs.gnu.org To: Platon Pronko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 31 18:03:45 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 1l6G8W-0006K5-PW for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jan 2021 18:03:44 +0100 Original-Received: from localhost ([::1]:42878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6G8V-00037h-4k for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jan 2021 12:03:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41676) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6G6u-0002cE-Ku for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2021 12:02:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46313) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l6G6r-00076U-PJ for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2021 12:02:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l6G6r-0000L2-Ko for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2021 12:02:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Jan 2021 17:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45792 X-GNU-PR-Package: emacs Original-Received: via spool by 45792-submit@debbugs.gnu.org id=B45792.16121125121284 (code B ref 45792); Sun, 31 Jan 2021 17:02:01 +0000 Original-Received: (at 45792) by debbugs.gnu.org; 31 Jan 2021 17:01:52 +0000 Original-Received: from localhost ([127.0.0.1]:57859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l6G6h-0000Kd-NP for submit@debbugs.gnu.org; Sun, 31 Jan 2021 12:01:51 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:28657 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1l6G6e-0000KO-9X for 45792@debbugs.gnu.org; Sun, 31 Jan 2021 12:01:50 -0500 Original-Received: (qmail 3724 invoked by uid 3782); 31 Jan 2021 17:01:41 -0000 Original-Received: from acm.muc.de (p2e5d5e05.dip0.t-ipconnect.de [46.93.94.5]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 31 Jan 2021 18:01:41 +0100 Original-Received: (qmail 14566 invoked by uid 1000); 31 Jan 2021 17:01:40 -0000 Content-Disposition: inline In-Reply-To: <81a72c8d-b92c-2eea-5ef3-ec4988634095@gmail.com> 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:199019 Archived-At: Hello, Platon. On Sun, Jan 31, 2021 at 15:11:11 +0300, Platon Pronko wrote: > Hi! > Tested the commit, the issue is gone - both with and without (not > (minibufferp)). Thanks! I'll mark the bug as closed, just as soon as your other observation has been dealt with. > However I noticed that (minibufferp) can return nil when it is called > on *Minibuf-1* (I noticed this when suddenly dvorak was enabled in > minibuffer even though (not (minibufferp)) guard was still in the > code). > Here's some debug code I used to check minibufferp return: > (define-minor-mode dvorak-minor-mode "Use english-dvorak input method." :lighter nil > (message (format "%s %s" (buffer-name (current-buffer)) (minibufferp))) > (if (and dvorak-minor-mode (not (minibufferp))) > (activate-input-method "english-dvorak"))) > (define-global-minor-mode global-dvorak-mode dvorak-minor-mode dvorak-minor-mode) > (global-dvorak-mode t) > And here's sample output in the *Message* buffer: > For information about GNU Emacs and the GNU system, type C-h C-a. > *scratch* nil > Loading quail/latin-post...done > *Minibuf-0* t > *Messages* nil > *Echo Area 0* nil > *Echo Area 1* nil > *load* nil > *Minibuf-1* nil <<-- here it thinks that Minibuf-1 is not a minibuffer > *Minibuf-0* t > Is this supposed to happen? No, it is most definitely not, and well done for spotting it. It's taken me most of the afternoon to fix it, and I still don't understand fully what's causing it. But, basically, the minibuffers are kept on a Lisp list, one minibuffer per recursive depth. They are nconc'd onto the end of the list as they are created, and minibufferp works by seeing if the buffer is a member of this list. Before my fix, the major mode of the newly created minibuffer was getting set before it was in its place on the list. I presume something in this major mode setting was trying to get a minibuffer, for some reason, when the minibuffer list was not in a consistent state. I've changed the order of these operations, so that the new minibuffer is firmly in the list before its mode gets set. The problem appears to have been fixed. Give me half an hour (or so), and I will have committed this fix to the Emacs repository master branch. Again, thanks for spotting such an obscure bug. > Best regards, > Platon Pronko -- Alan Mackenzie (Nuremberg, Germany).