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

Previous Next

Package: emacs;

Reported by: Pieter van Oostrum <pieter <at> vanoostrum.org>

Date: Wed, 27 Nov 2019 22:07:01 UTC

Severity: normal

Found in version 27.0.50

Full log


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

From: Pieter van Oostrum <pieter <at> vanoostrum.org>
To: Phil Sainty <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: Sun, 1 Dec 2019 19:40:14 +0100
Pieter van Oostrum wrote:

 > Phil Sainty wrote:
 > 
 >  > On 1/12/19 8:23 PM, Pieter van Oostrum wrote:
 >  > > Here it is, compressed. I am loading the uncompressed file,
 >  > > of course.
 >  > 
 >  > Without bidi-inhibit-bpa, visual-line-mode is certainly brutal
 >  > with this file (I've been waiting several minutes for Emacs 27
 >  > to respond to `end-of-buffer').
 >  > 
 >  > However, for me, bidi-inhibit-bpa comprehensively deals to that.
 >  > 
 >  > Is it possible that you didn't recompile or reinstall Emacs in
 >  > the way you thought you had, after pulling Eli's changes?
 >  > 
 >  > Can you confirm that C-h v bidi-inhibit-bpa actually shows you
 >  > documentation about the variable?  If it doesn't, then setting
 >  > it will have no effect whatsoever.
 > 
 > This is what it says.
 > 
 > bidi-inhibit-bpa is a variable defined in ‘C source code’.
 > Its value is nil
 > 
 >   Calls these functions when changed: (#<subr set-buffer-redisplay>)
 > 
 > Documentation:
 > Non-nil means inhibit the Bidirectional Parentheses Algorithm.
 > Disabling the BPA makes redisplay faster, but might produce incorrect
 > display reordering of bidirectional text with embedded parentheses and
 > other bracket characters whose ’paired-bracket’ Unicode property is
 > non-nil, see ‘get-char-code-property’.
 > 
 > So yes, it is the right one.
 > 
 > Latest experiment:
 > 
 > Opened this version of Emacs. 
 > (setq bidi-inhibit-bpa t)
 > open the file extensions.json (i.e. without visual-line-mode)
 > go to the end of the buffer.
 > Emacs gets responsive again after about one minute.
 > Then I open a new frame (Cmd-N), the frame appears, so this proves that Emacs was responsive.
 > But after opening the frame, Emacs is unresponsive again with 100% CPU usage. After 30 minutes, I killed it.

That was without so-long-mode. I retried with so-long-mode, and now everything works as it should. Even in grep-mode when the culprit file has a hit, it appears in the grep buffer and I can scroll over it. As soon as I set bidi-inhibit-bpa  to nil again, it fails.

I saw that bidi-inhibit-bpa is now part of so-long-mode, so I am compiling the latest master now.
Thanks everybody for all the help.
-- 
Pieter van Oostrum <pieter <at> vanoostrum.org>
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]





This bug report was last modified 5 years and 191 days ago.

Previous Next


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