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

Previous Next

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