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

Package: emacs;

Reported by: Vincent Lefevre <vincent <at> vinc17.net>

Date: Thu, 26 Jun 2025 08:47:02 UTC

Severity: normal

Tags: notabug

Found in version 30.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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.




This bug report was last modified today.

Previous Next


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