GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Wed, 06 Jul 2022 15:31:09 +0000

>> That's wrong, sorry.  Try opening hugedictionary.json in these editors 
>> and you'll see the effect.
>
> I was thinking of much smaller files that Emacs chokes on but e.g. vim 
> does not.
>

Surely, different editors have different limits.  My aim was to set the 
limit as high as possible for Emacs.  As far as I can tell the only limit 
is now RAM.  I just tried:

for I in $(seq 1 600); do cat dictionary.json; done > monsterdictionary.json

which produces a file with a single 11GB (!) long line, and you can edit 
it almost as it it were a 1KB file with Emacs.

That being said, my main point here was that all editors disable 
non-essential features when they open "big" files, for some definition of 
"big".  Both VS Code and Atom (silently) disable most highlighting even 
for the 300KB long-line.xml file (only "short" lines are highlighted), and 
(silently) disable all highlighting for the 19MB dictionary.json file.

Previous Next

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