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

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?

Previous Next

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