bug#64535: 30.0.50; Spurious newlines in `prin1` output

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

In my tests, yes.

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

Because it's a wart.

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


        Stefan