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

Previous Next

Full log

Message #22 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: Sat, 15 Jul 2023 10:29:54 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 64535 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 10:46:28 -0400
> 
> > 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?
> 
> Bug#2866 fundamentally had nothing to do with `prin1`.  It was just
> another instance of "Emacs freezes when encountering a long line".
> 
> The patch installed back then fixed the problem for one particular (and
> quite uncommon) way to end up with a long line.  There are millions more
> ways to get that result, as you know, many of them much more common.
> 
> The only thing special about Bug#2866 is that it happened to be a case
> where the long line was generated by our own code and where Handa
> bothered to write a hack that kinda worked around the problem, leaving
> all the many other ways to walk into that problem just as opened
> as before.
> 
> We now have a general way to solve the problem.  I don't think it's
> always absolutely perfect, but it's definitely good enough that we can
> get rid of this odd hack.  And those user who set `long-line-threshold`
> to nil *and* happen to reproduce just the recipe in Bug#2866 would get
> what they ask for, IMO.

Is that a "no" to my proposal above?

Previous Next

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