GNU bug report logs - #56393
Actually fix the long lines display bug

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, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Wed, 20 Jul 2022 13:42:26 +0000

>> You mean, something like: "Increase the counter more for a large 
>> modification and less for a small modification, but increase it 
>> logarithmically to avoid increasing it too much for a large 
>> modification."?
>
> No, I mean explaining why we want to be more sensitive to small 
> modifications than to the large.  IOW, why we want to avoid linear 
> increments.
>
> My original proposal to limit the increment was because I wanted to 
> avoid overflowing the counter when several very large insertions are 
> made.  If this is the only reason, I think we should say that in a 
> comment there.
>

That's what I understood.  I did not decide to go for a logarithmical 
increase instead of a truncated increase to be more sensitive to small 
modifications than to large ones, but both (1) because it increases the 
counter less, and (2) because currently it will be used to make a 
distinction between a "small" and a "not small" modification, but I can 
imagine that perhaps some day for some other reason there could be a need 
to make a distinction between "large" and "very large" modifications, 
which wouldn't be possible with a truncated increase.

Is this better/clearer: "Increase the counter more for a large 
modification and less for a small modification.  Increase it 
logarithmically to avoid increasing it too much."?

Previous Next

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