bug#38407: 27.0.50; infinite loop with display of large file without newlines

[Pieter van Oostrum]

Eli Zaretskii wrote:

 > > Date: Thu, 28 Nov 2019 07:51:33 +0100
 > > From: Pieter van Oostrum <pieter@vanoostrum.org>
 > > Cc: 38407@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@vanoostrum.org>
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]