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: Thu, 08 Sep 2022 14:13:29 -0400
> 
> This is an uncontrived, "in the wild" log file that I was C-n and
> C-p'ing when I discovered this "non-problem."

Are you saying that this log file didn't have lines whose length is in
excess of the long-line-threshold value?  Then it's a bug that we
would like to investigate, so please tell more details, and perhaps
post an example of such a file.

If the file did have such very long lines, then the question is: are
your Emacs and your patience capable of coping with editing this file
with the long-line optimizations disabled?  If the answer is YES, all
you need to do is make the value of long-line-threshold higher, or
even set it to nil, and you get what Emacs did previously.  C-n and
C-p will work correctly.  It might take them forever to do their job,
but it will be done much more accurately.

> I speculate at least half your users would consider this a regression,
> although perhaps not one serious enough to revert your changes.  Some of
> them would consider this a bug.

It is a regression if it happens in files with reasonable line length.
It is not a regression if it happens in files with very long lines,
because before the change Emacs couldn't cope with such files at all,
to the degree that would cause users kill the Emacs session.  Now such
files _can_ be edited, but with some minor features working in
sub-optimal manner.  Specifically, wrt C-n/C-p, let me remind you that
the line-move-visual = t operation that you say doesn't always work
with very long lines, didn't exist at all before Emacs 23, so at least
one solution is to turn it off, if its occasional misbehavior is
unacceptable for you.