unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Platon Pronko <platon7pronko@gmail.com>
Cc: acm@muc.de, 45792@debbugs.gnu.org
Subject: bug#45792: 28.0.50; regression in commit c7c154bb, minibuffer is not closed after opening a file
Date: Sat, 16 Jan 2021 16:36:42 +0000	[thread overview]
Message-ID: <YAMWGmasCjzYTy3Q@ACM> (raw)
In-Reply-To: <75aca8c3-6c8f-2a66-399e-7116d99c91d3@gmail.com>

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





  parent reply	other threads:[~2021-01-16 16:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 16:09 bug#45792: 28.0.50; regression in commit c7c154bb, minibuffer is not closed after opening a file Platon Pronko
2021-01-12  9:06 ` martin rudalics
2021-01-12 10:29   ` Platon Pronko
2021-01-12 19:00 ` Alan Mackenzie
2021-01-16 16:36 ` Alan Mackenzie [this message]
2021-01-17  7:50   ` Platon Pronko
2021-01-30 18:35     ` Alan Mackenzie
2021-01-31  8:54       ` Platon Pronko
2021-01-31 11:50         ` Alan Mackenzie
2021-01-31 12:11           ` Platon Pronko
2021-01-31 17:01             ` Alan Mackenzie
2021-01-31 19:37               ` Platon Pronko
2021-01-31 20:06                 ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YAMWGmasCjzYTy3Q@ACM \
    --to=acm@muc.de \
    --cc=45792@debbugs.gnu.org \
    --cc=platon7pronko@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).