bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support to longlines-mode

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  larsi@gnus.org,
>   56335@debbugs.gnu.org
> Date: Mon, 04 Jul 2022 10:06:03 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If and when visual-line-mode becomes fast on long lines, we won't need
> > visual-line-mode for that.  Unlike longlines, visual-line-mode does
> > NOT insert newlines into the character stream examined by the display
> > code, it just breaks a visual line in certain places it considers
> > appropriate.  Thus, visual-line-mode cannot help where newlines do: in
> > breaking long lines into shorter ones.  It suffers from the same
> > problems as "normal" display, and any solution, if we find it, will
> > fix both.
> 
> Hi Eli,
> 
> I don't really understand.  If the visual breaking of lines works
> flawlessly for editing such file, longlines.el will not be needed
> anymore.  And I think it'd be better to have that and *not* insert
> newlines into a user's buffer.

The difference between these two methods may not be self-evident,
because they change the display in similar ways.  But they do it on
different levels: longlines does it _before_ the display code examines
the buffer text, whereas visual-line-mode is a feature implemented in
the display code itself, and does its job as buffer text is being
traversed.

The other part of this puzzle is the reason _why_ redisplay is slow
with long lines: it's because its design requires it to start its
layout decisions from the previous newline (that's a simplification,
but it describes what actually happens quite accurately).  In a buffer
with very long lines, this means starting very far away from point,
then examining all the many characters in-between.

Now, visual-line-mode still does all those layout decisions the same
way, it just produces a different layout.  So it, too, must start far
away and them march all the way back.  By contrast, under longlines
the display code can start from a much closer place, where longlines
inserted a newline.

I hope I've succeeded to explain why visual-line-mode cannot be as
fast as longlines, and why, if we find a way of speeding up
visual-line-mode, we'll see the same speedup in the "normal" display
(actually, it will be even faster, since visual-line-mode incurs some
additional processing in the display code).

> >> Now I'm going to check corner cases in longlines.el because the previous
> >> code used to replace space with soft newline. This patch should not
> >> replace any characters (just add soft newline)… but I could have missed
> >> some.
> >
> > Please indicate when you have a version that we should install.
> 
> Ok.  Could I add patch onto this bug report or should I create a new
> one?

No need for a new bug report, you can post here.

Thanks.