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

Previous Next

Full log

Message #569 received at 56393 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Wed, 20 Jul 2022 15:07:05 +0300

> Date: Tue, 19 Jul 2022 21:40:36 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> > Would it help if the tick were incremented by the number of inserted (or 
> > deleted or replaced) characters (perhaps limited by some reasonable 
> > value, like 1000)?  That would be an easy change, and I don't think it 
> > would break anything, since no current code relies on the exact value of 
> > the tick, and the value you get after some non-trivial operation on a 
> > buffer is generally unpredictable anyway. Would that make the tick 
> > usable for this task?
> 
> It would.  In fact it is not even necessary to record the exact number of 
> inserted/deleted/replaced characters.
> 
> > If you agree, I can make such a change (but feel free to do it 
> > yourself).
> >
> 
> I just did it, is this what you had in mind?  The tick is incremented 
> logarithmically.

Yes, thanks.  Perhaps add a comment inside modiff_incr explaining why
we do it logarithmically.  Otherwise, LGTM.

(Hmm... should we say something about this in NEWS?  Not that I expect
some code out there depend on the exact increments in MOFIFF...)

Previous Next

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