unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Phil Sainty <psainty@orcon.net.nz>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: so-long-mode and line-move-visual
Date: Sun, 08 May 2022 22:02:34 +1200	[thread overview]
Message-ID: <c71663b913de1914c00f7db28bdcfea3@webmail.orcon.net.nz> (raw)
In-Reply-To: <83sfpkwpb9.fsf@gnu.org>

Hi Eli,

The settings were arrived at by experimentation, and observing
what caused the fewest problems in severe cases.

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.  I'm also mostly concerned about the initial
opening of a file (to ensure Emacs doesn't freeze up simply by
visiting something), in which case that small portion is going
to be (typically) the beginning of the line, where performance
is good.

If the settings were otherwise, it can be extremely problematic
to simply move up and down in a buffer.  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.

Truncation meanwhile allows multiple enormous lines to be
visible at the same time, which can be terrible.  I've always
used the "one_line.json" example file from the question at
https://emacs.stackexchange.com/q/598 as a test case, and if I
create a multi-line file where each line is a copy of that (plus
a newline), then I can happily open that with default so-long
settings; but if I then M-x toggle-truncate-lines, Emacs freezes
so badly that I have to kill it.

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


-Phil




  reply	other threads:[~2022-05-08 10:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-08  5:44 so-long-mode and line-move-visual Eli Zaretskii
2022-05-08 10:02 ` Phil Sainty [this message]
2022-05-08 11:20   ` Eli Zaretskii
2022-05-08 12:24     ` Phil Sainty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c71663b913de1914c00f7db28bdcfea3@webmail.orcon.net.nz \
    --to=psainty@orcon.net.nz \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).