GNU bug report logs - #45792
28.0.50; regression in commit c7c154bb, minibuffer is not closed after opening a file

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Platon Pronko <platon7pronko <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 45792 <at> debbugs.gnu.org
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

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).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.