bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Mon, 18 Jul 2022 20:14:21 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@debbugs.gnu.org
> 
> Each buffer has a character-change tick counter, which is set to the value 
> of the buffer's tick counter (see `buffer-modified-tick'), each time text 
> in that buffer is inserted or deleted.  By comparing the values returned 
> by two individual calls of `buffer-chars-modified-tick', you can tell 
> whether a character change occurred in that buffer in between these calls.
> 
> What I'm interested in in this case is not simply "whether a character 
> change occurred", but "how many characters were added in the buffer".  I 
> want to calculate whether the long line optimizations should be enabled if 
> and only if two or more characters were added in the buffer since last 
> redisplay.  That is, neither if only one character was added in the buffer 
> (which is what happens during normal typing), nor if characters were 
> removed from the buffer.

Why just "added"?  Deletion of characters can also create long lines,
if the deleted characters are newlines.

Also, what if since last redisplay N characters were deleted and N
other characters were added?  Isn't there a good chance that the long
line optimizations could now be needed in that case?

BUF_CHARS_MODIFF will catch all of these, while just looking at the
buffer's size won't.

And that's on top of the main reason: BUF_CHARS_MODIFF exists for a
long time, so introducing yet another similar counter sounds like not
the best idea to me.