Package: emacs;
Reported by: adam plaice <plaice.adam+lists <at> gmail.com>
Date: Tue, 20 Aug 2019 10:31:02 UTC
Severity: normal
Merged with 37986
Found in version 27.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: adam plaice <plaice.adam+lists <at> gmail.com> To: 37097 <at> debbugs.gnu.org Subject: bug#37097: 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))
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.