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

Previous Next

Full log

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Platon Pronko <platon7pronko <at> gmail.com>
Cc: acm <at> muc.de, bug-gnu-emacs <at> gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: 28.0.50; regression in commit c7c154bb, minibuffer is not closed
 after opening a file
Date: Sat, 16 Jan 2021 16:36:42 +0000

Hello again, Platon.

On Mon, Jan 11, 2021 at 19:09:53 +0300, Platon Pronko wrote:
> When I open a file using C-x C-f, minibuffer does not close after I
> finish typing the filename
> - current window does not change at all, minibuffer stays open (as if
> Emacs "froze").
> Pressing C-g or any other key unfreezes the window and file is
> displayed.

What is happening is that Emacs is getting caught on a (sit-for 1000000)
in quail-minibuffer-message.  The good news is that it will respond
eventually.  The bad news is that 11½ days is a rather sluggish response
time.

> I bisected the problem to commit c7c154bb, "Fix incompleteness in the
> implementation of minibuffer-follows-selected-frame".

This commit has triggered the problem, which was there all along.  It is
not the cause of it.

> Problem is somehow related to the fact that I use dvorak input method.

More precisely, any input method which uses quail-activate to start
itself.  For testing, I actually switched to "german-postfix" in your
recipe, so as to be able actually to use Emacs after applying it.  ;-)

> The problem goes away if I comment out the section under "We've exited
> the recursive edit without an error" in minibuf.c.

That may be so, but it is the trigger for an existing problem rather
than being the problem itself.

> Steps to reproduce:

> 1. init.el contents:

> (define-minor-mode dvorak-minor-mode "Use english-dvorak input method." :lighter nil
>    (if
>      (not (string= " *Minibuf-0*" (buffer-name (current-buffer))))
>      (if dvorak-minor-mode (activate-input-method "english-dvorak"))))
> (define-global-minor-mode global-dvorak-mode dvorak-minor-mode dvorak-minor-mode)
> (global-dvorak-mode t)

> 2. Start emacs with: ./src/emacs -Q --eval '(load-file "~/.emacs.d/init.el")'

Just as a matter of interest, you can write that more easily as
./src/emacs -Q -l ~/.emacs.d/init.el.

> 3. Type C-x C-f, type in some text-file filename, press Return.

> 4. Observe no file being opened and "[DV@]" in minibuffer.

What happens is that read-minibuffer does its thing, then a C function
read_minibuf_unwind calls minibuffer-inactive-mode since the minibuffer
is no longer live.  This mode change calls (run-mode-hooks
'minibuffer-inactive-mode-hook), which as a side effect runs the hook
after-change-major-mode-hook, onto which define-global-mode has put
global-dvorak-mode-enable-in-buffers.  g-d-m-e-i-b calls
dvorak-minor-mode (for the expired minibuffer) which calls
activate-input-method, ....., then quail-minibuffer-message.

This last function is the one with the million second timeout.

Clearly, changing mode to minibuffer-inactive-mode shouldn't trigger the
input method mechanisms.  I'm not sure at the moment how to stop this
happening, so I can't as yet close the bug.

> In GNU Emacs 28.0.50 (build 15, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.17.4)
>   of 2021-01-11 built on the-big-maker
> Repository revision: c7c154bb5756e0ae71d342c5d8aabf725877f186
> Repository branch: HEAD
> Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
> System Description: Arch Linux

[ .... ]

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