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

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: vincent <at> vinc17.net
Cc: 78904 <at> debbugs.gnu.org
Subject: 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.

Previous Next

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