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

Previous Next

Full log

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

From: Pieter van Oostrum <pieter <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, 38407 <at> debbugs.gnu.org
Subject: Re: bug#38407: 27.0.50;
 infinite loop with display of large file without newlines
Date: Thu, 28 Nov 2019 19:30:50 +0100

Eli Zaretskii wrote:

 > > Date: Thu, 28 Nov 2019 07:51:33 +0100
 > > From: Pieter van Oostrum <pieter <at> vanoostrum.org>
 > > Cc: 38407 <at> debbugs.gnu.org
 > > 
 > > Normally I wouldn't open such a bizarre file, but I was doing an 'rgrep' on my home directory, and this was one of the files that came up in the grep results. When I was scrolling though the *grep* buffer, I got this problem. Then I decided to just open the file, to eliminate the possibility that grep-mode was one of the causes.
 > > 
 > > And yes, I checked it all with emacs -Q.
 > 
 > As an aside, using Text mode for such files, and visual-line-mode on
 > top of that, is exactly the opposite of what one should do to make
 > redisplay performance better.  Text mode resets
 > bidi-paragraph-direction to nil, which makes redisplay work harder
 > because it needs to find the beginning of the current paragraph each
 > time redisplay starts.  And visual-line-mode makes redisplay a bit
 > slower, because of the need to find a suitable point to break the
 > line.
 > 
 > So I suggest to use the default mode for visiting JSON files.

I did open it as .json, and also enabled global-so-long-mode, but still no joy.
The real culprit is visual-line-mode, because without it, it can scroll through the file, albeit slowly. But it does finish, whereas with visual-line-mode it keeps swallowing CPU-time, at least for hours.
The really bad thing is that it can't be interrupted. ^G does not really stop it. So when you encounter this problem the only way out is to externally abort Emacs, thereby risking to lose your work. And all the hassle to restart and set up what you were doing.

As I encounter this problem in real life with rgrep, I can't always avoid it. I am doing a massive cleanup in my home directory, and with rgrep I will occasionally encounter these nasty files. It happened a couple of times in the last weeks.

In Emacs 26, it is also slow, but the redisplay comes to an end, so I see this as a kind of regression. The timing with Emacs 26 is very similar to that in Emacs 27, except that it doesn't hang at the end. So my impression is that the real difference is when the scrolling reaches the end of the file. That also happens with M-> (end-of-buffer), which hangs indefinitely (or at least a long time that is virtually indistinguishable from indefinitely) in Emacs 27, but it does finish in Emacs 26.
-- 
Pieter van Oostrum <pieter <at> vanoostrum.org>
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

Previous Next

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