unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Robert Pluim <rpluim@gmail.com>
Cc: psainty@orcon.net.nz, pieter@vanoostrum.org, 38407@debbugs.gnu.org
Subject: bug#38407: 27.0.50; infinite loop with display of large file without newlines
Date: Thu, 05 Dec 2019 17:01:05 +0200	[thread overview]
Message-ID: <83fthyizpq.fsf@gnu.org> (raw)
In-Reply-To: <m21rtjnsfv.fsf@gmail.com> (message from Robert Pluim on Thu, 05 Dec 2019 08:27:00 +0100)

> From: Robert Pluim <rpluim@gmail.com>
> Cc: psainty@orcon.net.nz,  pieter@vanoostrum.org,  38407@debbugs.gnu.org
> Date: Thu, 05 Dec 2019 08:27:00 +0100
> 
> I see global-so-long-mode is off by default, do we want to enable it
> by default? It seems a dis-service to users to make them have to
> find out about it by themselves.

If we want something like that to be enabled by default, it "needs
work", IMO.  For starters, the default line length beyond which it
kicks in, 250 characters, is waaay too low.  IME, problems start with
much longer lines, perhaps more than 10000 characters.  It would be
too radical, IMO, to start disabling important features when no
tangible slowdown happens yet.

Also, I think we should try to detect the special cases like the one
which triggered this bug report, because there the slowdown is
absolutely unbearable.  So maybe we should lower the default of
so-long-threshold when we detect an opening bracket character at BOB
(a clear sign of JSON or similar format), and maybe lower it yet more
if visual-line-mode is also enabled.

And finally, we could have a related global minor mode which just
_suggests_ turning on so-long in a buffer when it detects these
situations, but doesn't actually turn it on automatically.  Such a
global mode could be turned on by default much easier, and perhaps
could also use somewhat lower thresholds (but not 250).

WDYT?





  reply	other threads:[~2019-12-05 15:01 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27 21:52 bug#38407: 27.0.50; infinite loop with display of large file without newlines Pieter van Oostrum
2019-11-27 23:38 ` Phil Sainty
2019-11-28  0:30 ` Phil Sainty
2019-11-28  1:22 ` Phil Sainty
2019-11-28  6:51   ` Pieter van Oostrum
2019-11-28 15:14     ` Eli Zaretskii
2019-11-28 18:30       ` Pieter van Oostrum
2019-11-28 18:53         ` Eli Zaretskii
2019-11-28 22:09           ` Pieter van Oostrum
2019-11-29  7:12             ` Eli Zaretskii
2019-11-29 11:48               ` Phil Sainty
2019-11-29 13:20                 ` Eli Zaretskii
2019-11-29 13:48                 ` Dmitry Gutov
2019-11-29 14:26                   ` Eli Zaretskii
2019-11-29 14:31                     ` Dmitry Gutov
2019-11-29 15:03                       ` Eli Zaretskii
2019-11-29 16:53                         ` Dmitry Gutov
2019-11-29 19:28                           ` Eli Zaretskii
2019-11-29 17:24               ` Pieter van Oostrum
2019-11-29 19:30                 ` Eli Zaretskii
2019-11-30  8:25                   ` Pieter van Oostrum
2019-12-01  7:23                   ` Pieter van Oostrum
2019-12-01 10:37                     ` Phil Sainty
2019-12-01 16:35                       ` Pieter van Oostrum
2019-12-01 18:40                         ` Pieter van Oostrum
2019-12-02 16:23                         ` Eli Zaretskii
2019-12-01 17:45                       ` Eli Zaretskii
2019-12-02 10:27                         ` Robert Pluim
2019-12-03 11:20                           ` Robert Pluim
2019-12-03 16:05                             ` Eli Zaretskii
2019-12-04  9:15                               ` Robert Pluim
2019-12-04 15:45                                 ` Eli Zaretskii
2019-12-05  7:27                                   ` Robert Pluim
2019-12-05 15:01                                     ` Eli Zaretskii [this message]
2019-12-05 20:38                                       ` Phil Sainty
2019-12-06  8:04                                         ` Eli Zaretskii
2019-12-07  1:28                                           ` Phil Sainty
2019-12-07  7:56                                             ` Eli Zaretskii
2019-11-28 15:06   ` Eli Zaretskii

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=83fthyizpq.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=38407@debbugs.gnu.org \
    --cc=pieter@vanoostrum.org \
    --cc=psainty@orcon.net.nz \
    --cc=rpluim@gmail.com \
    /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).