GNU bug report logs - #44517
28.0.50; Can't unselect minibuffer window

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44517 in the body.
You can then email your comments to 44517 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Cc: Alan Mackenzie <acm <at> muc.de>
Subject: 28.0.50; Can't unselect minibuffer window
Date: Sun, 08 Nov 2020 13:28:29 +0100

Hello,

since some days, I experience the following issue: when I call

  (read-from-minibuffer "Enter something: ")

and select a different window, the minibuffer window automatically gets
re-selected after a short period of time.

I did not yet figure out how to reproduce for emacs -Q; with the default
settings, it is not reproducible there.

With my setup, the issue gets fixed when I do

  (setq minibuffer-follows-selected-frame nil)

I CC Alan hoping 2ecbf4cfae, "Allow minibuffer to stay in its original
frame.  Tidy up this area." is related and he can help so that I can get
around finding a recipe or digging further (well, it's Sunday).

TIA,

Michael.


In GNU Emacs 28.0.50 (build 94, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
 of 2020-11-08 built on drachen
Repository revision: 1b2fde216cf9328578b6a6a9a8ce0ce51035304c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_COLLATE: C
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix

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

From: Alan Mackenzie <acm <at> muc.de>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: acm <at> muc.de, 44517 <at> debbugs.gnu.org
Subject: Re: 28.0.50; Can't unselect minibuffer window
Date: Sun, 8 Nov 2020 14:02:14 +0000

Hello, Michael.

On Sun, Nov 08, 2020 at 13:28:29 +0100, Michael Heerdegen wrote:

> Hello,

> since some days, I experience the following issue: when I call

>   (read-from-minibuffer "Enter something: ")

> and select a different window, ....

With the mouse?  With C-x o?

> .... the minibuffer window automatically gets re-selected after a
> short period of time.

How short?  0.5s, 2s, 10s?  Knowing this might help identify the
associated timer.

> I did not yet figure out how to reproduce for emacs -Q; with the
> default settings, it is not reproducible there.

> With my setup, the issue gets fixed when I do

>   (setq minibuffer-follows-selected-frame nil)

Thanks.  That suggests, vaguely, that the problem might be in the
function move_minibuffer_onto_frame (in src/minibuf.c), which takes no
action when minibuffer-follows-selected-frame is nil.

> I CC Alan hoping 2ecbf4cfae, "Allow minibuffer to stay in its original
> frame.  Tidy up this area." is related and he can help so that I can
> get around finding a recipe or digging further (well, it's Sunday).

I strongly suspect your bug and that patch are related.  Despite it
being Sunday, could you perhaps nevertheless dig around a bit in the
hope of finding a recipe.

Thanks!

> TIA,

> Michael.


> In GNU Emacs 28.0.50 (build 94, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
>  of 2020-11-08 built on drachen
> Repository revision: 1b2fde216cf9328578b6a6a9a8ce0ce51035304c
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
> System Description: Debian GNU/Linux bullseye/sid

> Configured features:
> XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
> INOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB
> TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2

> Important settings:
>   value of $LC_ALL: de_DE.utf8
>   value of $LC_COLLATE: C
>   value of $LC_TIME: C
>   value of $LANG: de_DE.utf8
>   locale-coding-system: utf-8-unix

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 44517 <at> debbugs.gnu.org
Subject: Re: 28.0.50; Can't unselect minibuffer window
Date: Sun, 08 Nov 2020 17:40:49 +0100

Alan Mackenzie <acm <at> muc.de> writes:

> >   (read-from-minibuffer "Enter something: ")
>
> > and select a different window, ....
>
> With the mouse?  With C-x o?

In any way I tried, actually.

> How short?  0.5s, 2s, 10s?  Knowing this might help identify the
> associated timer.

The time seems to differ.  It's between .1 and 1.0 seconds I would
guess.  BTW, setting `timer-list' or `timer-idle-list' to nil in the
active minibuffer didn't change the behavior.

> I strongly suspect your bug and that patch are related.  Despite it
> being Sunday, could you perhaps nevertheless dig around a bit in the
> hope of finding a recipe.

Ok, let's see if can find one.  One more data point: with my setup I can
only reproduce when there are at least two visible frames.


Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 44517 <at> debbugs.gnu.org
Subject: Re: 28.0.50; Can't unselect minibuffer window
Date: Sun, 08 Nov 2020 17:48:10 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Ok, let's see if can find one.  One more data point: with my setup I can
> only reproduce when there are at least two visible frames.

That's actually already all you need to reproduce in emacs -Q: open a
second (window-system) frame.

Then eval something like (read-string "--> ") and hit C-x o.

Sometimes the minibuffer is re-selected right away, sometimes only after
hitting one more key like C-f.

Can you now reproduce?

TIA, Regards,

Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: acm <at> muc.de, 44517 <at> debbugs.gnu.org
Subject: Re: bug#44517: 28.0.50; Can't unselect minibuffer window
Date: Sun, 08 Nov 2020 19:05:52 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Date: Sun, 08 Nov 2020 17:40:49 +0100
> Cc: 44517 <at> debbugs.gnu.org
> 
> > How short?  0.5s, 2s, 10s?  Knowing this might help identify the
> > associated timer.
> 
> The time seems to differ.  It's between .1 and 1.0 seconds I would
> guess.  BTW, setting `timer-list' or `timer-idle-list' to nil in the
> active minibuffer didn't change the behavior.

This probably means that the delay is not due to a timer, but to a
call to sit-for or somesuch.  For example, if you type C-x, the echo
appears after a delay that doesn't have to do anything with timers.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 44517 <at> debbugs.gnu.org
Subject: Re: bug#44517: 28.0.50; Can't unselect minibuffer window
Date: Sun, 08 Nov 2020 18:25:11 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> This probably means that the delay is not due to a timer, but to a
> call to sit-for or somesuch.  For example, if you type C-x, the echo
> appears after a delay that doesn't have to do anything with timers.

Sounds reasonable, yes.

I didn't find out anything on the Lisp level.  `post-command-hook'
doesn't seem to be involved.  I traced some potentially related
functions, like `sit-for' and `select-window' but they were not called
when the issue happened.

Regards,

Michael.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, Alan Mackenzie <acm <at> muc.de>
Cc: 44517 <at> debbugs.gnu.org
Subject: Re: bug#44517: 28.0.50; Can't unselect minibuffer window
Date: Sun, 8 Nov 2020 18:31:01 +0100

>> Ok, let's see if can find one.  One more data point: with my setup I can
>> only reproduce when there are at least two visible frames.
>
> That's actually already all you need to reproduce in emacs -Q: open a
> second (window-system) frame.
>
> Then eval something like (read-string "--> ") and hit C-x o.
>
> Sometimes the minibuffer is re-selected right away, sometimes only after
> hitting one more key like C-f.

If yours is an optimized build, try with Alan's fix for Bug#44502.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: acm <at> muc.de, 44517 <at> debbugs.gnu.org
Subject: Re: bug#44517: 28.0.50; Can't unselect minibuffer window
Date: Sun, 08 Nov 2020 19:54:07 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: acm <at> muc.de,  44517 <at> debbugs.gnu.org
> Date: Sun, 08 Nov 2020 18:25:11 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > This probably means that the delay is not due to a timer, but to a
> > call to sit-for or somesuch.  For example, if you type C-x, the echo
> > appears after a delay that doesn't have to do anything with timers.
> 
> Sounds reasonable, yes.
> 
> I didn't find out anything on the Lisp level.  `post-command-hook'
> doesn't seem to be involved.  I traced some potentially related
> functions, like `sit-for' and `select-window' but they were not called
> when the issue happened.

There's sit_for in dispnew.c.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Alan Mackenzie <acm <at> muc.de>, 44517 <at> debbugs.gnu.org
Subject: Re: bug#44517: 28.0.50; Can't unselect minibuffer window
Date: Sun, 08 Nov 2020 18:57:16 +0100

martin rudalics <rudalics <at> gmx.at> writes:

> If yours is an optimized build, try with Alan's fix for Bug#44502.

Yes, an optimized build.  And the fix has been committed to master.
After fetching master and rebuilding I can't reproduce indeed.

Thanks,

Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 44517 <at> debbugs.gnu.org
Subject: Re: bug#44517: 28.0.50; Can't unselect minibuffer window
Date: Mon, 09 Nov 2020 11:50:55 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> martin rudalics <rudalics <at> gmx.at> writes:
>
> > If yours is an optimized build, try with Alan's fix for Bug#44502.
>
> Yes, an optimized build.  And the fix has been committed to master.
> After fetching master and rebuilding I can't reproduce indeed.

I leave it up to Alan whether this report can already be closed.

Thanks,

Michael.

Message #37 received at 44517-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 44517-done <at> debbugs.gnu.org
Subject: Re: bug#44517: 28.0.50; Can't unselect minibuffer window
Date: Mon, 9 Nov 2020 11:54:43 +0000

Hello, Michael.

On Mon, Nov 09, 2020 at 11:50:55 +0100, Michael Heerdegen wrote:
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> > martin rudalics <rudalics <at> gmx.at> writes:

> > > If yours is an optimized build, try with Alan's fix for Bug#44502.

> > Yes, an optimized build.  And the fix has been committed to master.
> > After fetching master and rebuilding I can't reproduce indeed.

> I leave it up to Alan whether this report can already be closed.

Sorry I havn't been in touch again.  I got tied up with another problem
of switching frames, which I eventually solved by putting

    (redirect-frame-focus frame nil)

into my site-start.el at a critical point.

I say this bug should now be closed, and thanks for raising it.  In
fact, I am closing it with this post.  It is good that the patch for bug
#44502 solved this one too.

> Thanks,

> Michael.

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