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: Mon, 09 May 2022 00:24:46 +1200	[thread overview]
Message-ID: <4ec7ea96745c3e007a6c85b2a75b0dff@webmail.orcon.net.nz> (raw)
In-Reply-To: <837d6ww9rq.fsf@gnu.org>

On 2022-05-08 23:20, Eli Zaretskii wrote:
>> With the option combo currently set by so-long, Emacs is only
>> displaying a small portion of a long line
> 
> 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?

I think you're only missing the sheer scale of the line lengths I
am referring to when I say that -- even if tall, an entire window
can *easily* be completely filled by only "a small portion" of the
kind of line I'm trying to protect against (for the example I gave
before, the line is 18 megabytes of JSON).


>> 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.

I'm not subscribed to help-gnu-emacs but I can see the thread in
the archives.  At first glance so-long does what it's supposed to
do with that symbol.ts file.  The description of the problem is a
bit vague, and I don't know why they'd see different performance
from the minor mode vs the major mode (the major mode for *.ts
files would presumably need to be causing the slowness directly,
but that would be unusual).  Alternatively, perhaps they're using
the "Doom Emacs" config which may still be enabling `font-lock-mode'
in `so-long-minor-mode' (which I told them was a bad idea when I
first became aware, but I don't think they changed it).

I can see that the user in question has had success with using
`longlines-mode', which does seem like a good solution for them.


> If you are still unconvinced, so be it.

I am.  I do appreciate that the defaults aren't ideal for all
cases, but I nevertheless believe they're the right defaults, as I
don't believe there's any particular collection of settings which
is optimal in all situations.  My overriding concern is preventing
Emacs from ever locking up due to merely visiting a file, so that
goal has always informed the default settings.


-Phil




      reply	other threads:[~2022-05-08 12:24 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
2022-05-08 11:20   ` Eli Zaretskii
2022-05-08 12:24     ` Phil Sainty [this message]

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=4ec7ea96745c3e007a6c85b2a75b0dff@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).