bug#57669: 29.0.50; C-n, C-p off under long lines

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 57669@debbugs.gnu.org
> From: dick <dick.r.chiang@gmail.com>
> Date: Fri, 09 Sep 2022 19:27:13 -0400
> 
> First you would need to construct a pathological case, like lots of Urdu
> and Hindi

There's nothing pathological about Hindi text.  In fact, the JSON and
XML files with very long lines, which we are using for this work,
quite frequently have non-ASCII text from various scripts, including
R2L scripts.  At least one of them I think went as far as showing
strings in every supported script.

> I would add that unless you're seriously considering replacing narrowing
> with my first-principles scheme (doubtful given how many hours you've
> invested in narrowing), this is all an academic exercise in
> oneupsmanship, which mind you, I am definitely game for.  If that
> suggests I believe I dealt with long lines better than you, you'd be
> correct.

This is not a pissing contest, at least not on our part.  We are
keenly interested in using any ideas that are correct, can be
implemented without too many complications, and provide significant
speedups, especially for very long lines.

For example, if the behaved_p idea, when implemented correctly
(i.e. when it takes into considerations _all_ the factors that violate
the monospace-ness assumption), can significantly speed up redisplay
in some situations, we would like to use it, at least when the
long_line_optimizations_p flag is set, if not always.  However, both
the correct conditions for behaved_p and the actual speedups still
need to be coded and measured, before we can make that decision.

One fundamental problem with the behaved_p idea is that the conditions
it should test, when implemented correctly, can change at any buffer
position, and at least for some of them (e.g., when a character is
displayed by glyphs from a display-table), we don't have any way of
knowing that in advance, except by examining every character, which
basically annuls any advantages of this idea.  So I'm not sure if this
idea is usable in a way that doesn't introduce subtle bugs.  But maybe
such bugs could be tolerable when lines are very long (which means the
relevant optimizations should only be taken when the
long_line_optimizations_p flag is set)?