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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: pieter <at> vanoostrum.org, 38407 <at> debbugs.gnu.org
Subject: bug#38407: 27.0.50; infinite loop with display of large file without newlines
Date: Thu, 28 Nov 2019 17:06:11 +0200

> Date: Thu, 28 Nov 2019 14:22:07 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: 38407 <at> debbugs.gnu.org
> 
> On 2019-11-28 10:52, Pieter van Oostrum wrote:
> > I used a 100KB json file from my Firefox profile
> 
> Out of interest I went looking for large JSON files in my own Firefox
> profiles, and the largest one I could find was an "extensions.json"
> which was also roughly 100K.  Curiously enough, everything was indeed
> dramatically slower than normal in that buffer, even in so-long-mode.
> 
> I also observed that many different human languages were present in
> the text, so I thought that bi-directional text processing might be a
> factor -- and indeed setting the debug option bidi-display-reordering
> to nil in that buffer made a *very* dramatic improvement to
> performance.

AFAICT, it isn't the bidi reordering in general, it's the BPA part of
the reordering -- that file has many embedded bracket characters.

I've added a new variable bidi-inhibit-bpa.  Try setting it non-nil,
and I think you will see performance very similar to disabling the
reordering entirely.  I guess that's another variable for so-long-mode
to futz with...

> Similarly, performance was good after using M-x find-file-literally
> to visit the file.

It makes very little sense to visit a text file with many non-ASCII
characters using find-file-literally, IMO.

Previous Next

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