bug#56393: Actually fix the long lines display bug

[Gregory Heytings]

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

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