bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Tue, 19 Jul 2022 12:49:33 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@debbugs.gnu.org
> 
> >> And it's inconvenient that you have to keep a copy of its previous 
> >> value around, using MODIFF != UNCHANGED_MODIFIED as I did earlier is 
> >> much easier.
> >
> > We could indeed keep using MODIFF != UNCHANGED_MODIFIED (and I'm not 
> > really sure why you decided it was not good enough: can you describe the 
> > problems using it?).
> >
> 
> The problem is that the loop under that condition is called whenever 
> redisplay_window is called. For a file like xdisp.c or dictionary.json, 
> that loop takes about 1 ms (on my laptop).  For a file with 150K lines, it 
> takes about 13 ms.  As I said earlier, I would prefer to avoid calling 
> that loop for normal typing, namely when only one character has been added 
> or removed from the buffer since the last redisplay.  IOW, I want to make 
> the heuristic more precise.

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.)

> > Alternatively, we could add a new member of 'struct buffer_text' called, 
> > say, unchanged_chars_modiff, and use it instead of MODIFF != 
> > UNCHANGED_MODIFIED in the same way as we use MODIFF != 
> > UNCHANGED_MODIFIED.
> >
> > My point is that if you want the member you added, unchanged_size, to be 
> > as responsive to text changes as BUF_CHARS_MODIFF, you will need to add 
> > code to increment it in all the places where we already do that with 
> > BUF_CHARS_MODIFF, and that sounds like redundancy, since we don't really 
> > care about how many characters were added/deleted/replaced.
> >
> 
> AFAIU that's not correct: like unchanged_modified, unchanged_size must be 
> updated only when redisplay ends, namely in 
> mark_window_display_accurate_1.

That's true, but I meant chars_modiff, not unchanged_chars_modiff.
The former is updated all over insdel.c, to catch all the possible
primitive operations that modify buffer text, so if you want to catch
those modifications, you need to do the same, more or less.