bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Tue, 19 Jul 2022 05:39:24 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@debbugs.gnu.org
> 
> To be honest, I don't really understand the purpose of BUF_CHARS_MODIFF. 
> As the comment in buffer.h explains: "It is set to modiff for each such 
> event, and never otherwise changed."  So it doesn't contain new 
> information.

Yes, it does: it allows you to keep track of changes to the buffer
text only, ignoring any other changes (like faces, overlays, etc.)
which affect the buffer's modified status.  The number itself is not
interesting, the only thing that is interesting is when the number
goes up -- this means the buffer text was changed in some way.

> And it's inconvenient that you have to keep a copy of its previous
> value around, using MODIFIED != UNCHANGED_MODIFIED as I did earlier
> is much easier.

We could indeed keep using MODIFIED != UNCHANGED_MODIFIED (and I'm not
really sure why you decided it was not good enough: can you describe
the problems using it?).  Alternatively, we could add a new member of
'struct buffer_text' called, say, unchanged_chars_modiff, and use it
instead of MODIFIED != UNCHANGED_MODIFIED in the same way as we use
MODIFIED != 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.