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

[Eli Zaretskii <eliz@gnu.org>]

> From: dick <dick.r.chiang@gmail.com>
> Cc: 57669@debbugs.gnu.org
> Date: Sat, 10 Sep 2022 08:51:50 -0400
> 
> monospace-p I agree is an heuristic like narrowing.  In the majority of
> cases of long lines, it applies the algebraic shortcut when it thinks it
> can get away with it.

My guess is that it disables the shortcut in any buffer that has
font-lock turned on.  Turning off font-lock is known to speed up
things significantly, even without the shortcut, but we thought that
turning it off would be asking too much.  Thus, a satisfactory
solution must work in the presence of faces and in the presence of
different fonts, because the real-life use cases where we see very
long lines use both.

So I think we can only apply such shortcuts when lines are very long,
in which case the resulting inaccuracies in layout calculations could
be perhaps tolerated.  I don't think it's feasible to apply them
always, because once we make behaved_p accurate enough (if that is at
all feasible), it will probably lose its attractiveness.

The other question is: if we apply these shortcuts when lines are very
long, what do we gain?  If performance becomes significantly better,
it would perhaps mean we can enlarge long-line-threshold's value, or
make the default narrowing region larger.  But I don't think we can
avoid the narrowing completely, because anything else will still scale
at least linearly with the line length, and so will at some point
become unbearably slow.