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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 19 Jul 2022 16:56:39 +0300

> Date: Tue, 19 Jul 2022 13:42:26 +0000
> From: Gregory Heytings <[email-masked]>
> cc: [email-masked], [email-masked], [email-masked]
> 
> > So you want to call the loop only when the buffer changed by two or more 
> > characters?  Did you try something like
> >
> >  MODIFF > UNCHANGED_MODIFIED + 1
> >
> > ?  (This could be optimized further to use a margin larger that 1.)
> 
> That doesn't work alas, otherwise I would have used that of course. 
> After C-u 100000 a, MODIFF - UNCHANGED_MODIFIED == 1 in a buffer without 
> fontification and == 2 in a buffer with fontification, which does what it 
> promises: it tells you that the buffer has been changed, but not how much.

Why is that a problem?  For this feature, we don't need the exact
number of modifications in character units.

> I pushed an improved version of the heuristic, which uses both MODIFF / 
> UNCHANGED_MODIFIED (to catch editing operations like M-% C-q C-j RET SPC 
> RET) and the buffer size to decide whether a new detection should be 
> performed.

Fine by me, but I think this is over-engineered.

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.

Thanks.