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 Lefevre <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 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?

Previous Next

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