GNU bug report logs - #78904
30.1; in a long directory pathname, "Cannot write backup file" is output with a spurious blank line

Previous Next

To reply to this bug, email your comments to 78904 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; in a long directory pathname, "Cannot write backup file" is
 output with a spurious blank line
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.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 78904 <at> debbugs.gnu.org
Subject: Re: bug#78904: 30.1;
 in a long directory pathname, "Cannot write backup file" is output
 with a spurious blank line
Date: Thu, 26 Jun 2025 12:22:11 +0300

tags 78904 notabug
thanks

> From: Vincent Lefevre <vincent <at> vinc17.net>
> 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.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78904 <at> debbugs.gnu.org
Subject: Re: bug#78904: 30.1; in a long directory pathname, "Cannot write
 backup file" is output with a spurious blank line
Date: Thu, 26 Jun 2025 11:30:32 +0200

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 <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 78904 <at> debbugs.gnu.org
Subject: Re: bug#78904: 30.1; in a long directory pathname, "Cannot write
 backup file" is output with a spurious blank line
Date: Thu, 26 Jun 2025 14:51:33 +0300

> Date: Thu, 26 Jun 2025 11:30:32 +0200
> From: Vincent Lefevre <vincent <at> vinc17.net>
> Cc: 78904 <at> 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?

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78904 <at> debbugs.gnu.org
Subject: Re: bug#78904: 30.1; in a long directory pathname, "Cannot write
 backup file" is output with a spurious blank line
Date: Thu, 26 Jun 2025 16:36:34 +0200

On 2025-06-26 14:51:33 +0300, Eli Zaretskii wrote:
> > Date: Thu, 26 Jun 2025 11:30:32 +0200
> > From: Vincent Lefevre <vincent <at> vinc17.net>
> > Cc: 78904 <at> 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 <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 78904 <at> debbugs.gnu.org
Subject: Re: bug#78904: 30.1; in a long directory pathname, "Cannot write
 backup file" is output with a spurious blank line
Date: Thu, 26 Jun 2025 17:47:31 +0300

> Date: Thu, 26 Jun 2025 16:36:34 +0200
> From: Vincent Lefevre <vincent <at> vinc17.net>
> Cc: 78904 <at> 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?

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78904 <at> debbugs.gnu.org
Subject: Re: bug#78904: 30.1; in a long directory pathname, "Cannot write
 backup file" is output with a spurious blank line
Date: Thu, 26 Jun 2025 17:02:23 +0200

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 <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 78904 <at> debbugs.gnu.org
Subject: Re: bug#78904: 30.1; in a long directory pathname, "Cannot write
 backup file" is output with a spurious blank line
Date: Thu, 26 Jun 2025 18:33:41 +0300

> Date: Thu, 26 Jun 2025 17:02:23 +0200
> From: Vincent Lefevre <vincent <at> vinc17.net>
> Cc: 78904 <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: vincent <at> vinc17.net
Cc: 78904 <at> debbugs.gnu.org
Subject: Re: bug#78904: 30.1;
 in a long directory pathname, "Cannot write backup file" is output
 with a spurious blank line
Date: Thu, 26 Jun 2025 19:11:07 +0300

> Cc: 78904 <at> debbugs.gnu.org
> Date: Thu, 26 Jun 2025 18:33:41 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > > > > 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: vincent <at> vinc17.net
Cc: 78904-done <at> debbugs.gnu.org
Subject: Re: bug#78904: 30.1;
 in a long directory pathname, "Cannot write backup file" is output
 with a spurious blank line
Date: Sat, 12 Jul 2025 09:52:38 +0300

> Cc: 78904 <at> debbugs.gnu.org
> Date: Thu, 26 Jun 2025 19:11:07 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Cc: 78904 <at> debbugs.gnu.org
> > Date: Thu, 26 Jun 2025 18:33:41 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > 
> > > > > > 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.

Previous Next

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