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

Previous Next

Full log

Message #536 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: Tue, 19 Jul 2022 17:19:55 +0300

> Date: Tue, 19 Jul 2022 14:06:17 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> > Why is that a problem?  For this feature, we don't need the exact number 
> > of modifications in character units.
> 
> Again, because I want to skip the long line detection code/overhead for 
> normal editing operation (typing one character at a time).

That's not the problem you presented.  You presented an opposite
problem: where inserting many characters bumps the tick by just 1.  I
asked why that is a problem.

> > Fine by me, but I think this is over-engineered.
> 
> Fine, but then you'd have to tell me how to do that in another way (that 
> is, how to not trigger the long line detection code when the buffer has 
> only changed a little), or to convince me that the 13 ms overhead is okay.

That's not what I'm saying.  I'm saying that not recomputing the long
lines when the user types "C-u 100000 a" is not a catastrophe.

> > Also, please add a comment there explaining the heuristics, including 
> > the cases we know about where the counters could behave "strangely" or 
> > fail to catch changes.
> >
> 
> I'll do that.

Thanks.

Previous Next

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