GNU bug report logs - #56683
29.0.50; long lines fix doesn't work correctly when lines are truncated

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, andreyorst <at> gmail.com, 56683 <at> debbugs.gnu.org
Subject: bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated
Date: Tue, 26 Jul 2022 12:50:51 +0000

>>> Maybe optionally.  Or maybe displaying a message/warning suggesting 
>>> that.  I don't like disabling truncate-lines unconditionally in such 
>>> buffers, I prefer leaving that to the user.
>>
>> The user would still have the choice to disable the automatic disabling 
>> by setting long-line-threshold to nil.
>
> Yes, I understand.  I still don't like it very much.  But if many users 
> will complain, we might change that before Emacs 29 is released.
>

Do I understand correctly that it's okay to do that on the feature (and 
later master) branch, and that it will be perhaps be revisited later?

>
> No, I said making the type of the struct member current_x a ptrdiff_t or 
> intmax_t will affect performance.  The above doesn't propose any such 
> changes, it just enlarges the "infinity" value.  With that value, lines 
> up to (/ (expt 2 31) 20) => 107374182 (i.e. about 107 million 
> characters) per line will still display correctly with truncate-lines 
> when hscrolling is required.
>

Sorry, I misunderstood what you said.  Now it's much clearer, indeed. 
But still, as you say, that puts a limit at around 100 MB, which isn't 
"that much" nowadays.

Previous Next

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