GNU bug report logs - #64535
30.0.50; Spurious newlines in `prin1` output

Previous Next

Full log

Message #16 received at 64535 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 64535 <at> debbugs.gnu.org
Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output
Date: Fri, 14 Jul 2023 16:38:08 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 64535-done <at> debbugs.gnu.org
> Date: Thu, 13 Jul 2023 19:11:48 -0400
> 
> >> Can we get rid of this quirk now, please?
> >
> > I'm okay with getting rid of it, with two conditions:
> >
> >   . removing newline insertion in the scenario of bug#2866 leaves
> >     Emacs sufficiently performant, even in the unoptimized build, and
> >   . we will still insert a newline if long-line-threshold is nil
> 
> That means we'd keep the code and make it even larger.

The second item, maybe.  What about the first -- is bug#2866 solved by
long-line handling in Emacs 29?

> > IOW, I don't want us to bring back regressions as result of
> > this cleanup.
> 
> That wouldn't be a cleanup, then.  IOW you're asking me to make the
> quirk even bigger.  I'd rather keep the quirk as-is, in that case.

Sorry, I don't understand: what was the reason for you to start this
discussion?  IOW, why is it good to get rid of the code which inserts
those newlines?  I don't suppose you wanted to bring back the bug
which was the reason for adding that code, did you?

I can suggest another solution: remove that code, but make sure
long-line-threshold is reset to its default value locally in the
buffer where prin1 is producing its output?  Would that be more
acceptable?

Previous Next

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