Re: so-long-mode and line-move-visual

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 08 May 2022 22:02:34 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: emacs-devel@gnu.org
> 
> With the option combo currently set by so-long, Emacs is only
> displaying a small portion of a long line, and basic cursor
> movements are only moving around within that visible area, so
> it's less likely that the user will cause themselves problems
> by moving point.

How is this consistent with this:

  (defcustom so-long-variable-overrides
    '((bidi-inhibit-bpa . t)
      (bidi-paragraph-direction . left-to-right)
      (buffer-read-only . t)
      (global-hl-line-mode . nil)
      (line-move-visual . t)
      (show-paren-mode . nil)
      (truncate-lines . nil)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
      (which-func-mode . nil))

When truncate-lines is nil, lines are NOT truncated, so long lines
wrap around, and we display whole lines (at least their parts that fit
in a window, and windows nowadays tend to be very tall), not their
small portions.  What am I missing?

> A nil line-move-visual risks the user accidentally skipping to the
> end of an enormous line (which may be very bad for performance),
> whereas a non-nil value protects them from that.

That's not what happens in reality, though.  When line-move-visual is
nil, C-n moves to the next _physical_ line by looking for the next
newline in the buffer (via 'memchr'), which is very fast.  If lines
are truncated, this move to the next physical line skips large
portions of the buffer that are not visible on display, and skips them
very quickly.  By contrast, with line-move-visual non-nil, we use
simulation of the display code to find what is the character directly
below the cursor on the next visual line, and that requires us to
traverse all the characters in-between, loading fonts and colors,
computing the metrics of the font glyphs, etc.

> As such, I don't think these defaults should be changed.

Well, I found the defaults sub-optimal in the case someone presented
on help-gnu-emacs yesterday, thus my question.  If you are still
unconvinced, so be it.