GNU bug report logs - #37986
emacsclient doesn't open a frame when waiting for input in the minibuffer

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 37986 in the body.
You can then email your comments to 37986 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: Sébastien Chapuis <sebastien <at> chapu.is>
To: bug-gnu-emacs <at> gnu.org
Subject: emacsclient doesn't open a frame when waiting for input in the
 minibuffer
Date: Wed, 30 Oct 2019 17:00:00 +0800

[Message part 1 (text/plain, inline)]

This bug occurs on emacs master branch but it doesn't with emacs 26.2

Steps to reproduce:

terminal #1:
$ git clone --recursive git://git.savannah.gnu.org/emacs.git
$ cd emacs && ./autogen.sh
$ mkdir build && cd build
$ ../configure --prefix=/opt/emacs-git --with-modules --with-xwidgets
--with-imagemagick
$ make install
$ /opt/emacs-git/bin/emacs --fg-daemon -Q

Open another terminal (terminal #2):
$ /opt/emacs-git/bin/emacsclient -n -c BIG_FILE.txt
the command doesn't return and no frame is opened.
On the terminal #1, there is this output:

```
Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is
unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this
problem.
Starting Emacs daemon.
File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or
(l)iterally
File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or
(l)iterally
```

Open a 3rd terminal (terminal #3):
$ /opt/emacs-git/bin/emacsclient -n -c
A new frame is opened with this message in the minibuffer:
`File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or
(l)iterally`
If I type `y`, a new frame is opened (from terminal #2) with the file
BIG_FILE.txt in its buffer.


Let me know if you need more details.

Thanks,
Sebastien Chapuis.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sébastien Chapuis <sebastien <at> chapu.is>
Cc: 37986 <at> debbugs.gnu.org
Subject: Re: bug#37986: emacsclient doesn't open a frame when waiting for
 input in the minibuffer
Date: Wed, 30 Oct 2019 18:17:58 +0200

severity 37097 normal
merge 37986 37097
thanks

> From: Sébastien Chapuis <sebastien <at> chapu.is>
> Date: Wed, 30 Oct 2019 17:00:00 +0800
> 
> $ git clone --recursive git://git.savannah.gnu.org/emacs.git
> $ cd emacs && ./autogen.sh
> $ mkdir build && cd build
> $ ../configure --prefix=/opt/emacs-git --with-modules --with-xwidgets --with-imagemagick
> $ make install
> $ /opt/emacs-git/bin/emacs --fg-daemon -Q
> 
> Open another terminal (terminal #2):
> $ /opt/emacs-git/bin/emacsclient -n -c BIG_FILE.txt
> the command doesn't return and no frame is opened.
> On the terminal #1, there is this output:
> 
> ```
> Warning: due to a long standing Gtk+ bug
> https://gitlab.gnome.org/GNOME/gtk/issues/221
> Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
> Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
> Starting Emacs daemon.
> File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or (l)iterally 
> File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or (l)iterally 
> ```
> 
> Open a 3rd terminal (terminal #3):
> $ /opt/emacs-git/bin/emacsclient -n -c
> A new frame is opened with this message in the minibuffer:
> `File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or (l)iterally`
> If I type `y`, a new frame is opened (from terminal #2) with the file BIG_FILE.txt in its buffer.

Thanks.  Can you see if the problem goes away if you revert commit
49fc040?

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

From: Sébastien Chapuis <sebastien <at> chapu.is>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37986 <at> debbugs.gnu.org
Subject: Re: bug#37986: emacsclient doesn't open a frame when waiting for
 input in the minibuffer
Date: Fri, 1 Nov 2019 21:35:24 +0800

[Message part 1 (text/plain, inline)]

Yes, the problem goes away after reverting this commit.

Thanks Eli

Le jeu. 31 oct. 2019 à 00:18, Eli Zaretskii <eliz <at> gnu.org> a écrit :

> severity 37097 normal
> merge 37986 37097
> thanks
>
> > From: Sébastien Chapuis <sebastien <at> chapu.is>
> > Date: Wed, 30 Oct 2019 17:00:00 +0800
> >
> > $ git clone --recursive git://git.savannah.gnu.org/emacs.git
> > $ cd emacs && ./autogen.sh
> > $ mkdir build && cd build
> > $ ../configure --prefix=/opt/emacs-git --with-modules --with-xwidgets
> --with-imagemagick
> > $ make install
> > $ /opt/emacs-git/bin/emacs --fg-daemon -Q
> >
> > Open another terminal (terminal #2):
> > $ /opt/emacs-git/bin/emacsclient -n -c BIG_FILE.txt
> > the command doesn't return and no frame is opened.
> > On the terminal #1, there is this output:
> >
> > ```
> > Warning: due to a long standing Gtk+ bug
> > https://gitlab.gnome.org/GNOME/gtk/issues/221
> > Emacs might crash when run in daemon mode and the X11 connection is
> unexpectedly lost.
> > Using an Emacs configured with --with-x-toolkit=lucid does not have this
> problem.
> > Starting Emacs daemon.
> > File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or
> (l)iterally
> > File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or
> (l)iterally
> > ```
> >
> > Open a 3rd terminal (terminal #3):
> > $ /opt/emacs-git/bin/emacsclient -n -c
> > A new frame is opened with this message in the minibuffer:
> > `File BIG_FILE.txt is large (11.9 MiB), really open? (y)es or (n)o or
> (l)iterally`
> > If I type `y`, a new frame is opened (from terminal #2) with the file
> BIG_FILE.txt in its buffer.
>
> Thanks.  Can you see if the problem goes away if you revert commit
> 49fc040?
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sébastien Chapuis <sebastien <at> chapu.is>
Cc: 37986 <at> debbugs.gnu.org
Subject: Re: bug#37986: emacsclient doesn't open a frame when waiting for
 input in the minibuffer
Date: Fri, 01 Nov 2019 15:43:25 +0200

> From: Sébastien Chapuis <sebastien <at> chapu.is>
> Date: Fri, 1 Nov 2019 21:35:24 +0800
> Cc: 37986 <at> debbugs.gnu.org
> 
> Yes, the problem goes away after reverting this commit.

OK, thanks for testing.

I'm going to revert that commit in a couple of days, unless a better
solution comes to mind.  We tried to fix a minor aesthetic problem,
and instead got ourself several much more grave ones.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: sebastien <at> chapu.is
Cc: 37986 <at> debbugs.gnu.org
Subject: Re: bug#37986: emacsclient doesn't open a frame when waiting for
 input in the minibuffer
Date: Thu, 07 Nov 2019 19:18:54 +0200

> Date: Fri, 01 Nov 2019 15:43:25 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 37986 <at> debbugs.gnu.org
> 
> > From: Sébastien Chapuis <sebastien <at> chapu.is>
> > Date: Fri, 1 Nov 2019 21:35:24 +0800
> > Cc: 37986 <at> debbugs.gnu.org
> > 
> > Yes, the problem goes away after reverting this commit.
> 
> OK, thanks for testing.
> 
> I'm going to revert that commit in a couple of days, unless a better
> solution comes to mind.  We tried to fix a minor aesthetic problem,
> and instead got ourself several much more grave ones.

Done.  Please see that this issue is now resolved.

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

From: Sébastien Chapuis <sebastien <at> chapu.is>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37986 <at> debbugs.gnu.org
Subject: Re: bug#37986: emacsclient doesn't open a frame when waiting for
 input in the minibuffer
Date: Fri, 8 Nov 2019 13:25:18 +0800

[Message part 1 (text/plain, inline)]

Yes it works now.

Thank you !

Le ven. 8 nov. 2019 à 01:19, Eli Zaretskii <eliz <at> gnu.org> a écrit :

> > Date: Fri, 01 Nov 2019 15:43:25 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 37986 <at> debbugs.gnu.org
> >
> > > From: Sébastien Chapuis <sebastien <at> chapu.is>
> > > Date: Fri, 1 Nov 2019 21:35:24 +0800
> > > Cc: 37986 <at> debbugs.gnu.org
> > >
> > > Yes, the problem goes away after reverting this commit.
> >
> > OK, thanks for testing.
> >
> > I'm going to revert that commit in a couple of days, unless a better
> > solution comes to mind.  We tried to fix a minor aesthetic problem,
> > and instead got ourself several much more grave ones.
>
> Done.  Please see that this issue is now resolved.
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sébastien Chapuis <sebastien <at> chapu.is>
Cc: 37986-done <at> debbugs.gnu.org
Subject: Re: bug#37986: emacsclient doesn't open a frame when waiting for
 input in the minibuffer
Date: Fri, 08 Nov 2019 08:55:59 +0200

> From: Sébastien Chapuis <sebastien <at> chapu.is>
> Date: Fri, 8 Nov 2019 13:25:18 +0800
> Cc: 37986 <at> debbugs.gnu.org
> 
> Yes it works now.

Thanks for testing, closing the bug.

Previous Next

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