From unknown Sat Aug 09 09:36:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line Resent-From: Vincent Lefevre Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 08:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 78904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 78904@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17509275659825 (code B ref -1); Thu, 26 Jun 2025 08:47:02 +0000 Received: (at submit) by debbugs.gnu.org; 26 Jun 2025 08:46:05 +0000 Received: from localhost ([127.0.0.1]:48492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUiFB-0002YN-2P for submit@debbugs.gnu.org; Thu, 26 Jun 2025 04:46:05 -0400 Received: from lists.gnu.org ([2001:470:142::17]:40976) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUiF8-0002Xf-Tb for submit@debbugs.gnu.org; Thu, 26 Jun 2025 04:46:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUiF1-0001mj-EW for bug-gnu-emacs@gnu.org; Thu, 26 Jun 2025 04:45:56 -0400 Received: from joooj.vinc17.net ([2001:4b99:1:3:216:3eff:fe20:ac98]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUiEv-0004mx-HH for bug-gnu-emacs@gnu.org; Thu, 26 Jun 2025 04:45:55 -0400 Received: from smtp-qaa.vinc17.net (2a02-8428-1b1d-4d01-96a9-491d-7b48-ba31.rev.sfr.net [IPv6:2a02:8428:1b1d:4d01:96a9:491d:7b48:ba31]) by joooj.vinc17.net (Postfix) with ESMTPSA id 4E877176; Thu, 26 Jun 2025 10:45:44 +0200 (CEST) Received: by qaa.vinc17.org (Postfix, from userid 1000) id 20076CA044B; Thu, 26 Jun 2025 10:45:43 +0200 (CEST) From: Vincent Lefevre Date: Thu, 26 Jun 2025 10:45:42 +0200 Message-ID: <87y0te28nd.fsf@qaa.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2001:4b99:1:3:216:3eff:fe20:ac98; envelope-from=vincent@vinc17.net; helo=joooj.vinc17.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 1. mkdir a-very-very-very-very-very-very-long-directory-pathname 2. cd a-very-very-very-very-very-very-long-directory-pathname 3. touch foo 4. emacs -Q --eval '(defun find-backup-file-name (fn) (list "/"))' foo 5. Modify the buffer. 6. Save with C-x C-s The following is output: Cannot write backup file; backing up in ~/.emacs.d/%backup%~ but with a spurious blank line below, i.e. the echo area takes 2 lines instead of a single one. Note: it seems that what matters is the length of the absolute directory pathname. In my case, this is /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname This occurs whether Emacs uses its own interface or runs in a terminal. In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.49, cairo version 1.18.4) of 2025-03-30, modified by Debian built on sbuild Windowing system distributor 'The X.Org Foundation', version 11.0.12101016 System Description: Debian GNU/Linux 13 (trixie) Configured using: 'configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/30.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/30.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/30.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/30.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --with-cairo --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/emacs-30.1+1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_COLLATE: POSIX value of $LC_CTYPE: C.UTF-8 value of $LC_TIME: en_DK.utf8 value of $LANG: C.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: display-time-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-14/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-14/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-14/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-15/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-15/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-15/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-16/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-16/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-16/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-17/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-17/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-17/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-18/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-18/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-18/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-19/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-19/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-19/emacs /usr/share/emacs/site-lisp/elpa/po-mode-0.23.1/po-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.23.1/po-mode-autoloads /usr/share/emacs/site-lisp/elpa/po-mode-0.23.1/po-mode hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.23.1/po-mode /usr/share/emacs/site-lisp/elpa/po-mode-0.23.1/po-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.23.1/po-mode-pkg /usr/share/emacs/site-lisp/flim/sasl hides /usr/share/emacs/30.1/lisp/net/sasl /usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/30.1/lisp/language/thai-word Features: (shadow sort mail-extr cl-extra help-mode warnings compile comint ansi-osc ansi-color ring comp-run comp-common rx emacsbug message yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cus-start time cc-styles cc-align cc-engine cc-vars cc-defs w3m-load mmm-auto mmm-vars mmm-utils mmm-compat cus-edit pp cus-load wid-edit po-mode-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 153724 11952) (symbols 48 11962 0) (strings 32 37588 3766) (string-bytes 1 1225292) (vectors 16 19566) (vector-slots 8 481647 76139) (floats 8 52 6) (intervals 56 370 0) (buffers 992 12)) From unknown Sat Aug 09 09:36:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 09:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vincent Lefevre Cc: 78904@debbugs.gnu.org Received: via spool by 78904-submit@debbugs.gnu.org id=B78904.175092974416129 (code B ref 78904); Thu, 26 Jun 2025 09:23:01 +0000 Received: (at 78904) by debbugs.gnu.org; 26 Jun 2025 09:22:24 +0000 Received: from localhost ([127.0.0.1]:48569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUioJ-0004C4-92 for submit@debbugs.gnu.org; Thu, 26 Jun 2025 05:22:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44898) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUioG-0004Bn-Cx; Thu, 26 Jun 2025 05:22:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUioA-00032G-Ge; Thu, 26 Jun 2025 05:22:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vRMPrdIZAVHLuzSwfzgJ0fr+SmuPsfeI55exwgDUm2A=; b=Bj0UlXNHS0CT 8bCtQsKFP0AVjR114pI86SRFvyy1G8COi7B7OQPU9QW0WfDimkSzLXTh0eFcqCxsbkFbtNEis1ZsI 0N5OVk7RDToyo4yEuALkNluWTp9jli769jQe1e0b8zvqsKfjYcG/RKcMXxvPXmnadIpd0F0qrki3f SWEHVG7ltQ6uFPytdGtygj1y8GHSju9FAGvcBYI/wuo0SK0H+yH2rqwD7MaPchSKP67fhUmwSgSAH yqyce9CQ5jEC6RAbJzLuWp1rjIouvLwn2vtXZ1M9zjHI0Y278le0KCQj28GBr5lff/sik4sxmQpOK LRE9Wgb209i6tPVhh15NdQ==; Date: Thu, 26 Jun 2025 12:22:11 +0300 Message-Id: <868qledfi4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87y0te28nd.fsf@qaa.vinc17.org> (message from Vincent Lefevre on Thu, 26 Jun 2025 10:45:42 +0200) References: <87y0te28nd.fsf@qaa.vinc17.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 78904 notabug thanks > From: Vincent Lefevre > Date: Thu, 26 Jun 2025 10:45:42 +0200 > > > 1. mkdir a-very-very-very-very-very-very-long-directory-pathname > 2. cd a-very-very-very-very-very-very-long-directory-pathname > 3. touch foo > 4. emacs -Q --eval '(defun find-backup-file-name (fn) (list "/"))' foo > 5. Modify the buffer. > 6. Save with C-x C-s > > The following is output: > > Cannot write backup file; backing up in ~/.emacs.d/%backup%~ > > but with a spurious blank line below, i.e. the echo area takes 2 lines > instead of a single one. If you switch to the *Messages* buffer, do you see there a message like this: Saving file /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname ? If so, this is the long message, shown before the "Cannot write backup file", and it causes the mini-window to resize to 2 screen lines instead of just 1. This resize remains in effect for the following echo-area messages, to avoid the annoying back-and-forth jumps of the mode line. If you don't like this behavior, customize the option resize-mini-windows to the value t (and see its doc string for more details about this feature). This behavior is intended, not a bug. From unknown Sat Aug 09 09:36:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line Resent-From: Vincent Lefevre Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 09:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Eli Zaretskii Cc: 78904@debbugs.gnu.org Received: via spool by 78904-submit@debbugs.gnu.org id=B78904.175093024324495 (code B ref 78904); Thu, 26 Jun 2025 09:31:01 +0000 Received: (at 78904) by debbugs.gnu.org; 26 Jun 2025 09:30:43 +0000 Received: from localhost ([127.0.0.1]:48601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUiwM-0006MO-Gr for submit@debbugs.gnu.org; Thu, 26 Jun 2025 05:30:42 -0400 Received: from cventin.lip.ens-lyon.fr ([140.77.13.17]:50808) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUiwI-00060F-UB for 78904@debbugs.gnu.org; Thu, 26 Jun 2025 05:30:39 -0400 Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.98.2) (envelope-from ) id 1uUiwC-00000000pnF-24YV; Thu, 26 Jun 2025 11:30:32 +0200 Date: Thu, 26 Jun 2025 11:30:32 +0200 From: Vincent Lefevre Message-ID: <20250626093032.GC2472@cventin.lip.ens-lyon.fr> References: <87y0te28nd.fsf@qaa.vinc17.org> <868qledfi4.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <868qledfi4.fsf@gnu.org> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/2.2.13+86 (bb2064ae) vl-169878 (2025-02-08) X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-06-26 12:22:11 +0300, Eli Zaretskii wrote: > If you switch to the *Messages* buffer, do you see there a message > like this: > > Saving file /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname > > ? I'm wondering whether this is useful as it is not visible: immediately overwritten by "Cannot write backup file...". > If so, this is the long message, shown before the "Cannot write > backup file", and it causes the mini-window to resize to 2 screen > lines instead of just 1. This resize remains in effect for the > following echo-area messages, to avoid the annoying back-and-forth > jumps of the mode line. OK, but this is not what I observe: it reduces to just 1 line for Wrote /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname/foo So this seems inconsistent. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon) From unknown Sat Aug 09 09:36:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 11:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Vincent Lefevre Cc: 78904@debbugs.gnu.org Received: via spool by 78904-submit@debbugs.gnu.org id=B78904.175093871032044 (code B ref 78904); Thu, 26 Jun 2025 11:52:02 +0000 Received: (at 78904) by debbugs.gnu.org; 26 Jun 2025 11:51:50 +0000 Received: from localhost ([127.0.0.1]:48829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUl8v-0008Kk-FB for submit@debbugs.gnu.org; Thu, 26 Jun 2025 07:51:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52632) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUl8r-0008KT-77 for 78904@debbugs.gnu.org; Thu, 26 Jun 2025 07:51:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUl8k-0008UA-2u; Thu, 26 Jun 2025 07:51:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KahalJGXAvAJygv4XCkh4oe/C3vi51wiq1+540ohv9g=; b=Bc/DdUgu26wt NSWlOBnSkNnyZIipgD9NyFJDyfbRDOpw0ktRc4d2v0kI5LFAOEFmTU9pSfm1XE2wGGjYE6Z+QGWK+ ixBBakzkgBxZgv/W5HvFngKN2gM14/tWylY9lexSzrz8FGSjcuLhsRTCGSFDi1jpYsos/QoLKGSDB CbT5zA6hCwXQ+LVxKKPUZxZqQoGfUpYGmaJr6cbjtOvOTTjbzbclATXsMJrE0pLnQRLcWcQ81WDq8 g5CAbipgbscy7/D5g3GSFZ0ARG9XOzwcGPJvVsqcApOY3iR6GSaPy5QKh1+IcYvF/qtC1tqo3Je3P OVlsJhL2ZePqYrVb49ZgYg==; Date: Thu, 26 Jun 2025 14:51:33 +0300 Message-Id: <867c0yd8l6.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <20250626093032.GC2472@cventin.lip.ens-lyon.fr> (message from Vincent Lefevre on Thu, 26 Jun 2025 11:30:32 +0200) References: <87y0te28nd.fsf@qaa.vinc17.org> <868qledfi4.fsf@gnu.org> <20250626093032.GC2472@cventin.lip.ens-lyon.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 26 Jun 2025 11:30:32 +0200 > From: Vincent Lefevre > Cc: 78904@debbugs.gnu.org > > On 2025-06-26 12:22:11 +0300, Eli Zaretskii wrote: > > If you switch to the *Messages* buffer, do you see there a message > > like this: > > > > Saving file /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname > > > > ? > > I'm wondering whether this is useful as it is not visible: > immediately overwritten by "Cannot write backup file...". Only because the buffer to save was very small. Large buffers take longer to save. But this is immaterial: Emacs does that in many cases, and it logs all messages are in a buffer for that reason: that you could then go back and look at them. > > If so, this is the long message, shown before the "Cannot write > > backup file", and it causes the mini-window to resize to 2 screen > > lines instead of just 1. This resize remains in effect for the > > following echo-area messages, to avoid the annoying back-and-forth > > jumps of the mode line. > > OK, but this is not what I observe: it reduces to just 1 line for > > Wrote /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname/foo > > So this seems inconsistent. What is inconsistent, and why? From unknown Sat Aug 09 09:36:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line Resent-From: Vincent Lefevre Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 14:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Eli Zaretskii Cc: 78904@debbugs.gnu.org Received: via spool by 78904-submit@debbugs.gnu.org id=B78904.175094860311093 (code B ref 78904); Thu, 26 Jun 2025 14:37:02 +0000 Received: (at 78904) by debbugs.gnu.org; 26 Jun 2025 14:36:43 +0000 Received: from localhost ([127.0.0.1]:51703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUniU-0002sr-Vt for submit@debbugs.gnu.org; Thu, 26 Jun 2025 10:36:43 -0400 Received: from cventin.lip.ens-lyon.fr ([140.77.13.17]:40420) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUniS-0002sB-7S for 78904@debbugs.gnu.org; Thu, 26 Jun 2025 10:36:40 -0400 Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.98.2) (envelope-from ) id 1uUniM-000000005uw-0Vfl; Thu, 26 Jun 2025 16:36:34 +0200 Date: Thu, 26 Jun 2025 16:36:34 +0200 From: Vincent Lefevre Message-ID: <20250626143634.GB21782@cventin.lip.ens-lyon.fr> References: <87y0te28nd.fsf@qaa.vinc17.org> <868qledfi4.fsf@gnu.org> <20250626093032.GC2472@cventin.lip.ens-lyon.fr> <867c0yd8l6.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <867c0yd8l6.fsf@gnu.org> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/2.2.13+86 (bb2064ae) vl-169878 (2025-02-08) X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-06-26 14:51:33 +0300, Eli Zaretskii wrote: > > Date: Thu, 26 Jun 2025 11:30:32 +0200 > > From: Vincent Lefevre > > Cc: 78904@debbugs.gnu.org > > > > On 2025-06-26 12:22:11 +0300, Eli Zaretskii wrote: > > > If you switch to the *Messages* buffer, do you see there a message > > > like this: > > > > > > Saving file /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname > > > > > > ? > > > > I'm wondering whether this is useful as it is not visible: > > immediately overwritten by "Cannot write backup file...". > > Only because the buffer to save was very small. Large buffers take > longer to save. > > But this is immaterial: Emacs does that in many cases, and it > logs all messages are in a buffer for that reason: that you could then > go back and look at them. OK for the logging in the *Messages* buffer. What I meant is that writing a message to the echo area is useless if it is not visible (as being overwritten almost immediately). Or at least, I don't think that outputting the full pathname in the echo area is useful when the message does not fit on one line. > > > If so, this is the long message, shown before the "Cannot write > > > backup file", and it causes the mini-window to resize to 2 screen > > > lines instead of just 1. This resize remains in effect for the > > > following echo-area messages, to avoid the annoying back-and-forth > > > jumps of the mode line. > > > > OK, but this is not what I observe: it reduces to just 1 line for > > > > Wrote /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname/foo > > > > So this seems inconsistent. > > What is inconsistent, and why? The fact that the echo area is not reduced for the "Cannot write backup file..." message but that it is reduced for the "Wrote..." message when this message fits on one line. For the 3 consecutive messages, the height of the echo area is 2, 2, 1, while if the goal is not to reduce it for the sequence of messages, this should be 2, 2, 2. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon) From unknown Sat Aug 09 09:36:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 14:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Vincent Lefevre Cc: 78904@debbugs.gnu.org Received: via spool by 78904-submit@debbugs.gnu.org id=B78904.175094926314190 (code B ref 78904); Thu, 26 Jun 2025 14:48:02 +0000 Received: (at 78904) by debbugs.gnu.org; 26 Jun 2025 14:47:43 +0000 Received: from localhost ([127.0.0.1]:51850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUnt8-0003gn-Ne for submit@debbugs.gnu.org; Thu, 26 Jun 2025 10:47:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35324) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUnt5-0003gU-OQ for 78904@debbugs.gnu.org; Thu, 26 Jun 2025 10:47:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUnsz-0007aV-B8; Thu, 26 Jun 2025 10:47:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=E4VFaxrGYpj7Jqvw4qOFpjy+GOkS0fekONr0Z2nO3lQ=; b=ae03/EPKn93X Cf1MFHowU+Z//7OlopFWr8DnBkOdJaKJ3iKOu6hu6q6a10niNj5KNrkEFvxpdhG+MYarSPMfhHWw9 nmE7E6AV3ysx32wYGca7x1vGjtvjGQV0VOo8FabB255bOKu1OEeDPstzWXSTNkXgL7Sx4lSoQNuDS r9k3+DpVLuIzGo7b8Li4ycRvYdVy3uFgZ4KEJ4T2INFnTZoQKvsEPo71Mp1cE+QaImsmgDrIhDO+J /3nMXeW1yCaGUT+MWFhvTAIHcXzQDEnjp7N5Im6L6pA95tYssGDUNPw0zZd5A4/V9WZX1lcUmQRq0 0qqyg+bNY/R7ikpe306F5A==; Date: Thu, 26 Jun 2025 17:47:31 +0300 Message-Id: <86pleqblvg.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <20250626143634.GB21782@cventin.lip.ens-lyon.fr> (message from Vincent Lefevre on Thu, 26 Jun 2025 16:36:34 +0200) References: <87y0te28nd.fsf@qaa.vinc17.org> <868qledfi4.fsf@gnu.org> <20250626093032.GC2472@cventin.lip.ens-lyon.fr> <867c0yd8l6.fsf@gnu.org> <20250626143634.GB21782@cventin.lip.ens-lyon.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 26 Jun 2025 16:36:34 +0200 > From: Vincent Lefevre > Cc: 78904@debbugs.gnu.org > > > > I'm wondering whether this is useful as it is not visible: > > > immediately overwritten by "Cannot write backup file...". > > > > Only because the buffer to save was very small. Large buffers take > > longer to save. > > > > But this is immaterial: Emacs does that in many cases, and it > > logs all messages are in a buffer for that reason: that you could then > > go back and look at them. > > OK for the logging in the *Messages* buffer. What I meant is that > writing a message to the echo area is useless if it is not visible > (as being overwritten almost immediately). The alternative is to slow down the command. I don't think it's justified in this case, since the "Saving..." message is not very important when the save is immediate. > Or at least, I don't think that outputting the full pathname in the > echo area is useful when the message does not fit on one line. ??? Of course, it's useful: it tells you what Emacs does. > > > > If so, this is the long message, shown before the "Cannot write > > > > backup file", and it causes the mini-window to resize to 2 screen > > > > lines instead of just 1. This resize remains in effect for the > > > > following echo-area messages, to avoid the annoying back-and-forth > > > > jumps of the mode line. > > > > > > OK, but this is not what I observe: it reduces to just 1 line for > > > > > > Wrote /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname/foo > > > > > > So this seems inconsistent. > > > > What is inconsistent, and why? > > The fact that the echo area is not reduced for the "Cannot write > backup file..." message but that it is reduced for the "Wrote..." > message when this message fits on one line. For the 3 consecutive > messages, the height of the echo area is 2, 2, 1, while if the > goal is not to reduce it for the sequence of messages, this should > be 2, 2, 2. Is this with the default value of resize-mini-windows or with that variable set to t? From unknown Sat Aug 09 09:36:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line Resent-From: Vincent Lefevre Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 15:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Eli Zaretskii Cc: 78904@debbugs.gnu.org Received: via spool by 78904-submit@debbugs.gnu.org id=B78904.175095015318443 (code B ref 78904); Thu, 26 Jun 2025 15:03:02 +0000 Received: (at 78904) by debbugs.gnu.org; 26 Jun 2025 15:02:33 +0000 Received: from localhost ([127.0.0.1]:52039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUo7V-0004nN-8S for submit@debbugs.gnu.org; Thu, 26 Jun 2025 11:02:33 -0400 Received: from cventin.lip.ens-lyon.fr ([140.77.13.17]:55838) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUo7S-0004n2-3L for 78904@debbugs.gnu.org; Thu, 26 Jun 2025 11:02:30 -0400 Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.98.2) (envelope-from ) id 1uUo7L-00000005mBr-2ULb; Thu, 26 Jun 2025 17:02:23 +0200 Date: Thu, 26 Jun 2025 17:02:23 +0200 From: Vincent Lefevre Message-ID: <20250626150223.GD21782@cventin.lip.ens-lyon.fr> References: <87y0te28nd.fsf@qaa.vinc17.org> <868qledfi4.fsf@gnu.org> <20250626093032.GC2472@cventin.lip.ens-lyon.fr> <867c0yd8l6.fsf@gnu.org> <20250626143634.GB21782@cventin.lip.ens-lyon.fr> <86pleqblvg.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86pleqblvg.fsf@gnu.org> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/2.2.13+86 (bb2064ae) vl-169878 (2025-02-08) X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-06-26 17:47:31 +0300, Eli Zaretskii wrote: > The alternative is to slow down the command. I don't think it's > justified in this case, since the "Saving..." message is not very > important when the save is immediate. > > > Or at least, I don't think that outputting the full pathname in the > > echo area is useful when the message does not fit on one line. > > ??? Of course, it's useful: it tells you what Emacs does. The user does not need all the details at this point. Having a truncated pathname, such as Saving file …-very-very-very-very-very-long-directory-pathname/foo... should be informative enough. The full message could be put in the *Messages* buffer if the user wishes to look at it. > > > What is inconsistent, and why? > > > > The fact that the echo area is not reduced for the "Cannot write > > backup file..." message but that it is reduced for the "Wrote..." > > message when this message fits on one line. For the 3 consecutive > > messages, the height of the echo area is 2, 2, 1, while if the > > goal is not to reduce it for the sequence of messages, this should > > be 2, 2, 2. > > Is this with the default value of resize-mini-windows or with that > variable set to t? With the default value of resize-mini-windows (e.g. with -Q). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon) From unknown Sat Aug 09 09:36:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 15:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Vincent Lefevre Cc: 78904@debbugs.gnu.org Received: via spool by 78904-submit@debbugs.gnu.org id=B78904.175095203227625 (code B ref 78904); Thu, 26 Jun 2025 15:34:02 +0000 Received: (at 78904) by debbugs.gnu.org; 26 Jun 2025 15:33:52 +0000 Received: from localhost ([127.0.0.1]:52475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUobn-0007BV-Vg for submit@debbugs.gnu.org; Thu, 26 Jun 2025 11:33:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35956) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUobl-0007BG-J6 for 78904@debbugs.gnu.org; Thu, 26 Jun 2025 11:33:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUobf-0006sX-J8; Thu, 26 Jun 2025 11:33:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=9H8wDPqo+NJDRBRpWt5+oQkrf0n1j+TGaoFGZHzqiY0=; b=p4e7Gs7g3u3wP8D4DXyM GsAxD0z9sw+5k16+I6kcapwcwp7WCUWa1HNY2v1frUhKFf9anInZNMB9aGbATW0cNfMJ4Iv6zS9Xr G8ytf4c0i+iWr2n4ZYtojkJZ8KfTvsa5Xmd6NLsUChuuafFn5HfRWj0IDkxbTzYpTm54Pb8KZvTj7 K9HwZQa06OF+Gchxcs+C7CfWQRMv+4dYK4ZGZCGDutCmPDsZyRkCE+NjZDoOhhCKgt5YuFVgZ4sqy BAnkBcAGTONwPbK8LPhPS1+g2qsMzK0AKvBj+9q7KBHIi+5icp7CqB1XYCC7TRkfcNuYVXakDm4LE ERrz3ISNjzd8hQ==; Date: Thu, 26 Jun 2025 18:33:41 +0300 Message-Id: <86o6uabjqi.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <20250626150223.GD21782@cventin.lip.ens-lyon.fr> (message from Vincent Lefevre on Thu, 26 Jun 2025 17:02:23 +0200) References: <87y0te28nd.fsf@qaa.vinc17.org> <868qledfi4.fsf@gnu.org> <20250626093032.GC2472@cventin.lip.ens-lyon.fr> <867c0yd8l6.fsf@gnu.org> <20250626143634.GB21782@cventin.lip.ens-lyon.fr> <86pleqblvg.fsf@gnu.org> <20250626150223.GD21782@cventin.lip.ens-lyon.fr> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 26 Jun 2025 17:02:23 +0200 > From: Vincent Lefevre > Cc: 78904@debbugs.gnu.org > > On 2025-06-26 17:47:31 +0300, Eli Zaretskii wrote: > > The alternative is to slow down the command. I don't think it's > > justified in this case, since the "Saving..." message is not very > > important when the save is immediate. > > > > > Or at least, I don't think that outputting the full pathname in the > > > echo area is useful when the message does not fit on one line. > > > > ??? Of course, it's useful: it tells you what Emacs does. > > The user does not need all the details at this point. Having a > truncated pathname, such as > > Saving file …-very-very-very-very-very-long-directory-pathname/foo... > > should be informative enough. The full message could be put in > the *Messages* buffer if the user wishes to look at it. Sorry, I disagree: truncating file names loses precious information. > > > > What is inconsistent, and why? > > > > > > The fact that the echo area is not reduced for the "Cannot write > > > backup file..." message but that it is reduced for the "Wrote..." > > > message when this message fits on one line. For the 3 consecutive > > > messages, the height of the echo area is 2, 2, 1, while if the > > > goal is not to reduce it for the sequence of messages, this should > > > be 2, 2, 2. > > > > Is this with the default value of resize-mini-windows or with that > > variable set to t? > > With the default value of resize-mini-windows (e.g. with -Q). I don't find that inconsistent. From unknown Sat Aug 09 09:36:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 16:12:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: vincent@vinc17.net Cc: 78904@debbugs.gnu.org Received: via spool by 78904-submit@debbugs.gnu.org id=B78904.17509542789235 (code B ref 78904); Thu, 26 Jun 2025 16:12:04 +0000 Received: (at 78904) by debbugs.gnu.org; 26 Jun 2025 16:11:18 +0000 Received: from localhost ([127.0.0.1]:52939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUpC1-0002Oq-UT for submit@debbugs.gnu.org; Thu, 26 Jun 2025 12:11:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41564) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUpBz-0002NZ-T1 for 78904@debbugs.gnu.org; Thu, 26 Jun 2025 12:11:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUpBt-0004WZ-6l; Thu, 26 Jun 2025 12:11:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=oM1EAVrafXypF7qAmeFVhDUIDrhp22v1N36YroQHl4M=; b=Bfpv84YdlPCA nFfVGdWDJKg0y8oNlK3rSzJ/MeC/YVI7+zYPFIz8jnxyvPWVd7slIHB1v20yXrcC8pd/DHBBj2dCN uY0fFt40b3c/I857usW5wDEhSzyyV+OIv4JUG7wgZKBmPnNSJbgQEba+mDjR33VrEnYDGId4uNLEE Bl8CwOAv1SOeUqfQZ2uRsXh0XbcQXpHpSX6P+d7xVTH0rOXJbQ6TbgbpMusrmII6euxehx4tOherz GL2ywUjOpEgtGGADd2xX3v+Fp1bi6Ffrbl0Ap9h9DBIagi9dELGYBmodwvR6utRrpAHEQLWCBGVfD qQeMunQPhvHSzwOzsuYqWg==; Date: Thu, 26 Jun 2025 19:11:07 +0300 Message-Id: <86ms9ubi04.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86o6uabjqi.fsf@gnu.org> (message from Eli Zaretskii on Thu, 26 Jun 2025 18:33:41 +0300) References: <87y0te28nd.fsf@qaa.vinc17.org> <868qledfi4.fsf@gnu.org> <20250626093032.GC2472@cventin.lip.ens-lyon.fr> <867c0yd8l6.fsf@gnu.org> <20250626143634.GB21782@cventin.lip.ens-lyon.fr> <86pleqblvg.fsf@gnu.org> <20250626150223.GD21782@cventin.lip.ens-lyon.fr> <86o6uabjqi.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 78904@debbugs.gnu.org > Date: Thu, 26 Jun 2025 18:33:41 +0300 > From: Eli Zaretskii > > > > > > What is inconsistent, and why? > > > > > > > > The fact that the echo area is not reduced for the "Cannot write > > > > backup file..." message but that it is reduced for the "Wrote..." > > > > message when this message fits on one line. For the 3 consecutive > > > > messages, the height of the echo area is 2, 2, 1, while if the > > > > goal is not to reduce it for the sequence of messages, this should > > > > be 2, 2, 2. > > > > > > Is this with the default value of resize-mini-windows or with that > > > variable set to t? > > > > With the default value of resize-mini-windows (e.g. with -Q). > > I don't find that inconsistent. To clarify: after Emacs shows the "Cannot write backup file" message, it waits for 1 second, to let you see the message. Then it shows the following message "Wrote file ...". The mini-window stays 2-line high as long as we show the first message, and shrinks back to one screen line after showing the second message. So we keep the mini-window 2-line high as long as the command runs, but shrink it back (if possible) once the command finishes. This is the intended behavior, and that is what you see. So I don't see any inconsistencies here, only the explicitly coded behavior. From unknown Sat Aug 09 09:36:35 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Vincent Lefevre Subject: bug#78904: closed (Re: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line) Message-ID: References: <86sej1gatl.fsf@gnu.org> <87y0te28nd.fsf@qaa.vinc17.org> X-Gnu-PR-Message: they-closed 78904 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: notabug Reply-To: 78904@debbugs.gnu.org Date: Sat, 12 Jul 2025 06:53:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1752303182-21571-1" This is a multi-part message in MIME format... ------------=_1752303182-21571-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #78904: 30.1; in a long directory pathname, "Cannot write backup file" is o= utput with a spurious blank line which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 78904@debbugs.gnu.org. --=20 78904: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78904 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1752303182-21571-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 78904-done) by debbugs.gnu.org; 12 Jul 2025 06:52:54 +0000 Received: from localhost ([127.0.0.1]:43141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uaU6Q-0005av-Gc for submit@debbugs.gnu.org; Sat, 12 Jul 2025 02:52:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33762) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uaU6M-0005aI-BV for 78904-done@debbugs.gnu.org; Sat, 12 Jul 2025 02:52:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uaU6C-0008Jq-NS; Sat, 12 Jul 2025 02:52:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=34chCVEQL903cpTYEA7lv/GVt/i+xcaEzMOhb4euBuM=; b=jwyWKVoQWOnm yeOFplbtFjXs/MvLkALElOwzsrzNaOedrgsGmE2WrNg+ygGoEUhPUyd8e+ti1gYrNMdKxgWAmXO5v 3yuRoNhEP23ohfLPx/Wb7r1j7qnZ7aH9U+thfLad7UcO1IJmrJrtCXT3ZnbIJTm7TLqQ3o5Dr5uQo LxEiZuli/vUBjHDUWt/yOO048N1snhwYTojLSIzVWGZ+oO2tdGJ7/1O1pMa/NLei7p7xQ5bVxMNFS F4mhzTewFQwW055QthxxQWDle/41NBrADXyXNnYsfeM/Y7Js85ouYjbq5ab5tRwUUzor8Vlw4lNws IQE4jUtY2rCHtLha+QGjjg==; Date: Sat, 12 Jul 2025 09:52:38 +0300 Message-Id: <86sej1gatl.fsf@gnu.org> From: Eli Zaretskii To: vincent@vinc17.net In-Reply-To: <86ms9ubi04.fsf@gnu.org> (message from Eli Zaretskii on Thu, 26 Jun 2025 19:11:07 +0300) Subject: Re: bug#78904: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line References: <87y0te28nd.fsf@qaa.vinc17.org> <868qledfi4.fsf@gnu.org> <20250626093032.GC2472@cventin.lip.ens-lyon.fr> <867c0yd8l6.fsf@gnu.org> <20250626143634.GB21782@cventin.lip.ens-lyon.fr> <86pleqblvg.fsf@gnu.org> <20250626150223.GD21782@cventin.lip.ens-lyon.fr> <86o6uabjqi.fsf@gnu.org> <86ms9ubi04.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78904-done Cc: 78904-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 78904@debbugs.gnu.org > Date: Thu, 26 Jun 2025 19:11:07 +0300 > From: Eli Zaretskii > > > Cc: 78904@debbugs.gnu.org > > Date: Thu, 26 Jun 2025 18:33:41 +0300 > > From: Eli Zaretskii > > > > > > > > What is inconsistent, and why? > > > > > > > > > > The fact that the echo area is not reduced for the "Cannot write > > > > > backup file..." message but that it is reduced for the "Wrote..." > > > > > message when this message fits on one line. For the 3 consecutive > > > > > messages, the height of the echo area is 2, 2, 1, while if the > > > > > goal is not to reduce it for the sequence of messages, this should > > > > > be 2, 2, 2. > > > > > > > > Is this with the default value of resize-mini-windows or with that > > > > variable set to t? > > > > > > With the default value of resize-mini-windows (e.g. with -Q). > > > > I don't find that inconsistent. > > To clarify: after Emacs shows the "Cannot write backup file" message, > it waits for 1 second, to let you see the message. Then it shows the > following message "Wrote file ...". The mini-window stays 2-line high > as long as we show the first message, and shrinks back to one screen > line after showing the second message. > > So we keep the mini-window 2-line high as long as the command runs, > but shrink it back (if possible) once the command finishes. This is > the intended behavior, and that is what you see. So I don't see any > inconsistencies here, only the explicitly coded behavior. No further comments, so I'm now closing this bug. ------------=_1752303182-21571-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 26 Jun 2025 08:46:05 +0000 Received: from localhost ([127.0.0.1]:48492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUiFB-0002YN-2P for submit@debbugs.gnu.org; Thu, 26 Jun 2025 04:46:05 -0400 Received: from lists.gnu.org ([2001:470:142::17]:40976) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUiF8-0002Xf-Tb for submit@debbugs.gnu.org; Thu, 26 Jun 2025 04:46:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUiF1-0001mj-EW for bug-gnu-emacs@gnu.org; Thu, 26 Jun 2025 04:45:56 -0400 Received: from joooj.vinc17.net ([2001:4b99:1:3:216:3eff:fe20:ac98]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUiEv-0004mx-HH for bug-gnu-emacs@gnu.org; Thu, 26 Jun 2025 04:45:55 -0400 Received: from smtp-qaa.vinc17.net (2a02-8428-1b1d-4d01-96a9-491d-7b48-ba31.rev.sfr.net [IPv6:2a02:8428:1b1d:4d01:96a9:491d:7b48:ba31]) by joooj.vinc17.net (Postfix) with ESMTPSA id 4E877176; Thu, 26 Jun 2025 10:45:44 +0200 (CEST) Received: by qaa.vinc17.org (Postfix, from userid 1000) id 20076CA044B; Thu, 26 Jun 2025 10:45:43 +0200 (CEST) From: Vincent Lefevre To: bug-gnu-emacs@gnu.org Subject: 30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line X-Debbugs-Cc: Date: Thu, 26 Jun 2025 10:45:42 +0200 Message-ID: <87y0te28nd.fsf@qaa.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2001:4b99:1:3:216:3eff:fe20:ac98; envelope-from=vincent@vinc17.net; helo=joooj.vinc17.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 1. mkdir a-very-very-very-very-very-very-long-directory-pathname 2. cd a-very-very-very-very-very-very-long-directory-pathname 3. touch foo 4. emacs -Q --eval '(defun find-backup-file-name (fn) (list "/"))' foo 5. Modify the buffer. 6. Save with C-x C-s The following is output: Cannot write backup file; backing up in ~/.emacs.d/%backup%~ but with a spurious blank line below, i.e. the echo area takes 2 lines instead of a single one. Note: it seems that what matters is the length of the absolute directory pathname. In my case, this is /home/vinc17/a-very-very-very-very-very-very-long-directory-pathname This occurs whether Emacs uses its own interface or runs in a terminal. In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.49, cairo version 1.18.4) of 2025-03-30, modified by Debian built on sbuild Windowing system distributor 'The X.Org Foundation', version 11.0.12101016 System Description: Debian GNU/Linux 13 (trixie) Configured using: 'configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/30.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/30.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/30.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/30.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --with-cairo --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/emacs-30.1+1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_COLLATE: POSIX value of $LC_CTYPE: C.UTF-8 value of $LC_TIME: en_DK.utf8 value of $LANG: C.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: display-time-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-14/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-14/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-14/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-15/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-15/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-15/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-16/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-16/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-16/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-17/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-17/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-17/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-18/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-18/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-18/emacs /usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-19/llvm-mode /usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-19/tablegen-mode /usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-19/emacs /usr/share/emacs/site-lisp/elpa/po-mode-0.23.1/po-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.23.1/po-mode-autoloads /usr/share/emacs/site-lisp/elpa/po-mode-0.23.1/po-mode hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.23.1/po-mode /usr/share/emacs/site-lisp/elpa/po-mode-0.23.1/po-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.23.1/po-mode-pkg /usr/share/emacs/site-lisp/flim/sasl hides /usr/share/emacs/30.1/lisp/net/sasl /usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/30.1/lisp/language/thai-word Features: (shadow sort mail-extr cl-extra help-mode warnings compile comint ansi-osc ansi-color ring comp-run comp-common rx emacsbug message yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cus-start time cc-styles cc-align cc-engine cc-vars cc-defs w3m-load mmm-auto mmm-vars mmm-utils mmm-compat cus-edit pp cus-load wid-edit po-mode-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 153724 11952) (symbols 48 11962 0) (strings 32 37588 3766) (string-bytes 1 1225292) (vectors 16 19566) (vector-slots 8 481647 76139) (floats 8 52 6) (intervals 56 370 0) (buffers 992 12)) ------------=_1752303182-21571-1--