Subject: bug#56393: Actually fix the long lines display bug

From: Eli Zaretskii <[email-masked]>
Date: Tue, 19 Jul 2022 17:19:55 +0300

> Date: Tue, 19 Jul 2022 14:06:17 +0000
> From: Gregory Heytings <[email-masked]>
> cc: [email-masked], [email-masked], [email-masked]
> 
> > 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.