GNU bug report logs - #38407
27.0.50; infinite loop with display of large file without newlines

Previous Next

Full log

Message #107 received at 38407 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: psainty <at> orcon.net.nz, pieter <at> vanoostrum.org, 38407 <at> debbugs.gnu.org
Subject: Re: bug#38407: 27.0.50; infinite loop with display of large file
 without newlines
Date: Thu, 05 Dec 2019 17:01:05 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: psainty <at> orcon.net.nz,  pieter <at> vanoostrum.org,  38407 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.