GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, dgutov <at> yandex.ru
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Sat, 13 Aug 2022 17:25:20 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Gregory Heytings <gregory <at> heytings.org>,  dgutov <at> yandex.ru,
>   56682 <at> debbugs.gnu.org
> Date: Sat, 13 Aug 2022 09:37:06 -0400
> 
> > Is 20MB single-line JSON file fairly representative of such files out
> > there?  Do we know of JSON file with much longer lines, for example
> > 50MB or 100MB?
> 
> IIUC it's very common for JSON files to be made of a single line, so the
> line length is the file's length and since those files are
> machine-generated I don't expect 100MB to be much less common than 20MB.

I think I'd prefer some actual data points.  It's clear that larger
JSON files can happen, the question is how frequently they do happen.

> > If 20MB is reasonably representative of the long-line JSON, then
> > perhaps at least json-mode could consider resetting
> > long-line-threshold to nil.
> 
> IIUC a nil value for `long-line-threshold` makes Emacs completely
> unusable with such long lines even if you disable all the bells
> and whistles.  Dmitry's suggestion is to skip the locked-narrowing in
> some cases, but not to set `long-line-threshold` to nil.

That's what I actually meant.

However, if much larger JSON files exist, we should first see what
that proposal produces with such larger files.

Previous Next

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