GNU bug report logs - #37097
27.0.50; Opening a "large file" with `emacsclient -c' does not create a frame

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 37097 in the body.
You can then email your comments to 37097 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: adam plaice <plaice.adam+lists <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Opening a "large file" with `emacsclient -c' does not create
 a frame
Date: Tue, 20 Aug 2019 12:30:40 +0200

When a file that exceeds the `large-file-warning-threshold' is opened
with `emacsclient -c $file', no frame is created.

* To reproduce:

1. Create a large enough file:

dd if=/dev/zero of=foobar bs=1024 count=10000

2. Start emacs daemon (with a custom socket to avoid colliding with an
   existing daemon):

emacs -Q --daemon=unmodified

3. Open the large file with emacsclient:

emacsclient -c --socket-name=unmodified foobar

(In all:

dd if=/dev/zero of=foobar bs=1024 count=10000
emacs -Q --daemon=unmodified
emacsclient -c --socket-name=unmodified foobar

)

* Expected result:

2. An emacs daemon is started.

3. A new frame is created with a dialog asking something like:

file foobar is large (nnn), really open? (y)es or (n)o or (l)iterally

* Actual result:

2. An emacs daemon is started.

3. No frame is created; the terminal just displays the usual
   "emacsclient message" (Waiting for Emacs...) and does nothing. The
   emacsclient can be normally killed with C-c (without killing the
   daemon).

(If one later accesses the *Messages* buffer, it contains:

Starting Emacs daemon.
When done with this frame, type M-x delete-frame
File foobar is large (9.8 MiB), really open? (y)es or (n)o or (l)iterally y
When done with a buffer, type C-x #

)

* Further information

1. If there is already a frame open,

(e.g.

emacsclient -c --socket-name=unmodified
emacsclient -c --socket-name=unmodified foobar
)

then the dialog asking `file foobar is large (nnn), really open? (y)es
or (n)o or (l)iterally' is displayed at the bottom of this existing frame.


2. If the emacsclient opening foobar is killed (with C-c) and afterwards a
   new frame is opened:

(e.g.

emacsclient -c --socket-name=unmodified foobar
# C-c
emacsclient -c --socket-name=unmodified

)

then the cursor is placed in the minibuffer of the new frame.  Even
though the dialog is not displayed, the standard responses (y, n, l)
still have (almost) the standard effect: pressing `y' or `l' will open
foobar in a new frame (in addition to the one that has just been
opened), `n' will prevent foobar from being opened.

However, if `y' or `l' was pressed, the "foobar frame" will not be
closable with `C-x C-c' (even if the foobar buffer itself is killed
with `C-x k' or `C-x #').  This frame can be closed with `C-x 5 0' or
one's standard window manager controls, though.

3. Since at no point does emacs actually crash, I haven't attached any
   gdb backtraces, but if it's useful, I could do that.

Thanks and best regards,
Adam



In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2019-08-19 built on adam
Repository revision: 50dc4ca8d02a466a7236765edf83ae7cfb02d74c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: Ubuntu 16.04.6 LTS

Recent messages:
Starting Emacs daemon.
When done with this frame, type M-x delete-frame
File foobar is large (9.8 MiB), really open? (y)es or (n)o or (l)iterally y
When done with a buffer, type C-x #
Mark set
previous-line: Beginning of buffer [2 times]
previous-line: Beginning of buffer
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils vc-git
diff-mode easymenu easy-mmode server tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 49876 6952)
 (symbols 48 6508 1)
 (strings 32 18201 2042)
 (string-bytes 1 577338)
 (vectors 16 10362)
 (vector-slots 8 146962 13862)
 (floats 8 29 37)
 (intervals 56 191 0)
 (buffers 992 13)
 (heap 1024 18041 1096))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: adam plaice <plaice.adam+lists <at> gmail.com>
Cc: 37097 <at> debbugs.gnu.org
Subject: Re: bug#37097: 27.0.50;
 Opening a "large file" with `emacsclient -c' does not create a frame
Date: Tue, 20 Aug 2019 17:44:33 +0300

> From: adam plaice <plaice.adam+lists <at> gmail.com>
> Date: Tue, 20 Aug 2019 12:30:40 +0200
> 
> 1. Create a large enough file:
> 
> dd if=/dev/zero of=foobar bs=1024 count=10000
> 
> 2. Start emacs daemon (with a custom socket to avoid colliding with an
>    existing daemon):
> 
> emacs -Q --daemon=unmodified
> 
> 3. Open the large file with emacsclient:
> 
> emacsclient -c --socket-name=unmodified foobar
> 
> (In all:
> 
> dd if=/dev/zero of=foobar bs=1024 count=10000
> emacs -Q --daemon=unmodified
> emacsclient -c --socket-name=unmodified foobar
> 
> )
> 
> * Expected result:
> 
> 2. An emacs daemon is started.
> 
> 3. A new frame is created with a dialog asking something like:
> 
> file foobar is large (nnn), really open? (y)es or (n)o or (l)iterally
> 
> * Actual result:
> 
> 2. An emacs daemon is started.
> 
> 3. No frame is created; the terminal just displays the usual
>    "emacsclient message" (Waiting for Emacs...) and does nothing. The
>    emacsclient can be normally killed with C-c (without killing the
>    daemon).

This works in Emacs 26, so I'm guessing this is another consequence of
fixing bug#24218, where we now create the frame only after visiting
the file.  So when we ask the question, we have no usable frame to ask
it in.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: plaice.adam+lists <at> gmail.com
Cc: 37097 <at> debbugs.gnu.org
Subject: Re: bug#37097: 27.0.50;
 Opening a "large file" with `emacsclient -c' does not create a frame
Date: Thu, 07 Nov 2019 19:21:54 +0200

> Date: Tue, 20 Aug 2019 17:44:33 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 37097 <at> debbugs.gnu.org
> 
> > 1. Create a large enough file:
> > 
> > dd if=/dev/zero of=foobar bs=1024 count=10000
> > 
> > 2. Start emacs daemon (with a custom socket to avoid colliding with an
> >    existing daemon):
> > 
> > emacs -Q --daemon=unmodified
> > 
> > 3. Open the large file with emacsclient:
> > 
> > emacsclient -c --socket-name=unmodified foobar
> > 
> > (In all:
> > 
> > dd if=/dev/zero of=foobar bs=1024 count=10000
> > emacs -Q --daemon=unmodified
> > emacsclient -c --socket-name=unmodified foobar
> > 
> > )
> > 
> > * Expected result:
> > 
> > 2. An emacs daemon is started.
> > 
> > 3. A new frame is created with a dialog asking something like:
> > 
> > file foobar is large (nnn), really open? (y)es or (n)o or (l)iterally
> > 
> > * Actual result:
> > 
> > 2. An emacs daemon is started.
> > 
> > 3. No frame is created; the terminal just displays the usual
> >    "emacsclient message" (Waiting for Emacs...) and does nothing. The
> >    emacsclient can be normally killed with C-c (without killing the
> >    daemon).
> 
> This works in Emacs 26, so I'm guessing this is another consequence of
> fixing bug#24218, where we now create the frame only after visiting
> the file.  So when we ask the question, we have no usable frame to ask
> it in.

Please try the latest master, I hope this is now solved.

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

From: Adam Plaice <plaiceadam <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37097 <at> debbugs.gnu.org
Subject: Re: bug#37097: 27.0.50; Opening a "large file" with `emacsclient -c'
 does not create a frame
Date: Thu, 7 Nov 2019 22:56:56 +0100

It is indeed fixed.

Thank you very much!

Adam

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Adam Plaice <plaiceadam <at> gmail.com>
Cc: 37097-done <at> debbugs.gnu.org
Subject: Re: bug#37097: 27.0.50; Opening a "large file" with `emacsclient -c'
 does not create a frame
Date: Fri, 08 Nov 2019 08:36:55 +0200

> From: Adam Plaice <plaiceadam <at> gmail.com>
> Date: Thu, 7 Nov 2019 22:56:56 +0100
> Cc: 37097 <at> debbugs.gnu.org
> 
> It is indeed fixed.
> 
> Thank you very much!

Great, closing the bug.

Previous Next

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