bug#56393: Actually fix the long lines display bug

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 20 Jul 2022 13:06:59 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@debbugs.gnu.org
> 
> 
> >
> > Yes, thanks.  Perhaps add a comment inside modiff_incr explaining why we 
> > do it logarithmically.
> >
> 
> 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.

> BTW, I think the threshold to trigger the long lines check in 
> redisplay_window could be increased a bit.  That is, instead of using 
> "MODIFF - UNCHANGED_MODIFIED > 4" I think we could use "> 8".  That would 
> exclude a few more common editing operations, e.g. C-k in a buffer with 80 
> columns.  WDYT?

I have no real experience on which to base my opinions, so feel free
to make the change.  Like I said, the threshold should be tuned, and
we may yet find the need to change it more than once.

> > (Hmm... should we say something about this in NEWS?  Not that I expect 
> > some code out there depend on the exact increments in MOFIFF...)
> >
> 
> That would be very surprising, because they are in general unpredictable, 
> and different depending on the context; e.g. MODIFF is incremented when 
> font locking is enabled.

OK, let's wait until someone hollers, if they do.