[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64535: 30.0.50; Spurious newlines in `prin1` output
From: |
Stefan Monnier |
Subject: |
bug#64535: 30.0.50; Spurious newlines in `prin1` output |
Date: |
Sat, 15 Jul 2023 11:20:50 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>> > 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?
It's saying that your proposal is to replace the current hack with
another hack, so indeed: not interested.
Stefan