GNU bug report logs - #39658
26.3; can't edit file with terminal escape sequences

Previous Next

To reply to this bug, email your comments to 39658 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: frederik <at> ofb.net
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; can't edit file with terminal escape sequences
Date: Tue, 18 Feb 2020 05:48:59 -0800

[Message part 1 (text/plain, inline)]

To reproduce, open the attached file in Emacs, and type C-x C-n. On my system Emacs uses 100% of CPU, indefinitely.

I can open the file in Vim (where it only lets me see the first part of the line) and in Gedit.

The file came from debugging Neomutt's use of curses. Thanks.


In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29 built on juergen
Recent messages:
Loading /home/frederik/.emacs.d/my-mark.el (source)...done
Loading /home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-site.el (source)...done
Loading /usr/share/emacs/26.3/lisp/progmodes/cc-mode.el.gz...
uncompressing cc-mode.el.gz...done
Loading /usr/share/emacs/26.3/lisp/progmodes/cc-mode.el.gz...done
Loading /home/frederik/.emacs.d/my-compile-next-makefile.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
When done with a buffer, type C-x #
next-line: End of buffer [2 times]
Making completion list...

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt'
 CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LC_TIME: en_GB
  value of $LANG: 
  value of $XMODIFIERS: 
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  global-auto-revert-mode: t
  shell-dirtrack-mode: t
  savehist-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Load-path shadows:
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-rd hides /usr/share/emacs/site-lisp/ess/ess-rd
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-rutils hides /usr/share/emacs/site-lisp/ess/ess-rutils
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/msdos hides /usr/share/emacs/site-lisp/ess/msdos
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-sp3-d hides /usr/share/emacs/site-lisp/ess/ess-sp3-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-r-gui hides /usr/share/emacs/site-lisp/ess/ess-r-gui
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-bugs-d hides /usr/share/emacs/site-lisp/ess/ess-bugs-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-trns hides /usr/share/emacs/site-lisp/ess/ess-trns
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-font-lock hides /usr/share/emacs/site-lisp/ess/ess-font-lock
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-dde hides /usr/share/emacs/site-lisp/ess/ess-dde
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-generics hides /usr/share/emacs/site-lisp/ess/ess-generics
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-gretl hides /usr/share/emacs/site-lisp/ess/ess-gretl
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-r-completion hides /usr/share/emacs/site-lisp/ess/ess-r-completion
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-help hides /usr/share/emacs/site-lisp/ess/ess-help
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-noweb hides /usr/share/emacs/site-lisp/ess/ess-noweb
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-sp4-d hides /usr/share/emacs/site-lisp/ess/ess-sp4-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-vst-d hides /usr/share/emacs/site-lisp/ess/ess-vst-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-mode hides /usr/share/emacs/site-lisp/ess/ess-mode
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-bugs-l hides /usr/share/emacs/site-lisp/ess/ess-bugs-l
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-roxy hides /usr/share/emacs/site-lisp/ess/ess-roxy
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-xls-d hides /usr/share/emacs/site-lisp/ess/ess-xls-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/make-regexp hides /usr/share/emacs/site-lisp/ess/make-regexp
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-sp6w-d hides /usr/share/emacs/site-lisp/ess/ess-sp6w-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-custom hides /usr/share/emacs/site-lisp/ess/ess-custom
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-s4-d hides /usr/share/emacs/site-lisp/ess/ess-s4-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-sas-a hides /usr/share/emacs/site-lisp/ess/ess-sas-a
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-noweb-mode hides /usr/share/emacs/site-lisp/ess/ess-noweb-mode
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/mouseme hides /usr/share/emacs/site-lisp/ess/mouseme
/home/frederik/.emacs.d/elpa/julia-mode-20191225.858/julia-mode hides /usr/share/emacs/site-lisp/ess/julia-mode
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-utils hides /usr/share/emacs/site-lisp/ess/ess-utils
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess hides /usr/share/emacs/site-lisp/ess/ess
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-sas-d hides /usr/share/emacs/site-lisp/ess/ess-sas-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-site hides /usr/share/emacs/site-lisp/ess/ess-site
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-sas-l hides /usr/share/emacs/site-lisp/ess/ess-sas-l
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/essd-els hides /usr/share/emacs/site-lisp/ess/essd-els
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-eldoc hides /usr/share/emacs/site-lisp/ess/ess-eldoc
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-r-args hides /usr/share/emacs/site-lisp/ess/ess-r-args
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-r-syntax hides /usr/share/emacs/site-lisp/ess/ess-r-syntax
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-julia hides /usr/share/emacs/site-lisp/ess/ess-julia
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-omg-l hides /usr/share/emacs/site-lisp/ess/ess-omg-l
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-sp5-d hides /usr/share/emacs/site-lisp/ess/ess-sp5-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-toolbar hides /usr/share/emacs/site-lisp/ess/ess-toolbar
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-arc-d hides /usr/share/emacs/site-lisp/ess/ess-arc-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-rdired hides /usr/share/emacs/site-lisp/ess/ess-rdired
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-lsp-l hides /usr/share/emacs/site-lisp/ess/ess-lsp-l
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-tracebug hides /usr/share/emacs/site-lisp/ess/ess-tracebug
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-sp6-d hides /usr/share/emacs/site-lisp/ess/ess-sp6-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-swv hides /usr/share/emacs/site-lisp/ess/ess-swv
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-mouse hides /usr/share/emacs/site-lisp/ess/ess-mouse
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-r-a hides /usr/share/emacs/site-lisp/ess/ess-r-a
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-noweb-font-lock-mode hides /usr/share/emacs/site-lisp/ess/ess-noweb-font-lock-mode
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-inf hides /usr/share/emacs/site-lisp/ess/ess-inf
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-jags-d hides /usr/share/emacs/site-lisp/ess/ess-jags-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-s3-d hides /usr/share/emacs/site-lisp/ess/ess-s3-d
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-r-package hides /usr/share/emacs/site-lisp/ess/ess-r-package
/home/frederik/.emacs.d/elpa/ess-20170109.628/lisp/ess-omg-d hides /usr/share/emacs/site-lisp/ess/ess-omg-d

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa epg gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
term/rxvt term/xterm xterm elec-pair cc-mode derived cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-langs cc-bytecomp
jka-compr rx edmacro kmacro autorevert filenotify ido ess-toolbar
ess-mouse mouseme thingatpt+ thingatpt browse-url ess-menu ess-swv
ess-noweb ess-noweb-font-lock-mode ess-bugs-l essd-els ess-sas-d
ess-sas-l ess-sas-a ess-sta-d ess-sta-l cc-vars cc-defs make-regexp
ess-sp6-d ess-dde ess-sp3-d ess-julia julia-mode julia-mode-latexsubs
ess-r-d ess-r-syntax ess-r-completion ess-roxy essddr noutline outline
hideshow ess-help ess-r-package ess-s-l ess ess-inf ess-tracebug tramp
tramp-compat tramp-loaddefs trampver ucs-normalize shell pcomplete
parse-time format-spec advice ess-mode ess-noweb-mode ess-utils
time-date ess-generics ess-custom executable ess-compat ess-site
savehist iflipb bind-key compile easy-mmode comint ansi-color ring cl
help-fns+ wid-edit help-fns radix-tree help-mode server finder-inf
gh-common marshal eieio-compat info package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 329454 16361)
 (symbols 48 32943 2)
 (miscs 40 103 133)
 (strings 32 71935 3550)
 (string-bytes 1 1946605)
 (vectors 16 47930)
 (vector-slots 8 883205 10966)
 (floats 8 113 448)
 (intervals 56 312 0)
 (buffers 992 16))

[nts (application/octet-stream, attachment)]

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

From: Robert Pluim <rpluim <at> gmail.com>
To: frederik <at> ofb.net
Cc: 39658 <at> debbugs.gnu.org
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Tue, 18 Feb 2020 14:58:22 +0100

>>>>> On Tue, 18 Feb 2020 05:48:59 -0800, frederik <at> ofb.net said:

    frederik> To reproduce, open the attached file in Emacs, and type C-x C-n. On my system Emacs uses 100% of CPU, indefinitely.
    frederik> I can open the file in Vim (where it only lets me see the first part of the line) and in Gedit.

    frederik> The file came from debugging Neomutt's use of curses. Thanks.

The problem is more likely to be the extremely long lines in the
file. If you have emacs-27 or emacs-master, you can try 'M-x
global-so-long-mode' before visiting the file, which attempts to
improve Emacs' behaviour in such cases.

Robert

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

From: frederik <at> ofb.net
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 39658 <at> debbugs.gnu.org
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Tue, 18 Feb 2020 06:15:10 -0800

[Message part 1 (text/plain, inline)]

On Tue, Feb 18, 2020 at 02:58:22PM +0100, Robert Pluim wrote:
>>>>>> On Tue, 18 Feb 2020 05:48:59 -0800, frederik <at> ofb.net said:
>
>    frederik> To reproduce, open the attached file in Emacs, and type C-x C-n. On my system Emacs uses 100% of CPU, indefinitely.
>    frederik> I can open the file in Vim (where it only lets me see the first part of the line) and in Gedit.
>
>    frederik> The file came from debugging Neomutt's use of curses. Thanks.
>
>The problem is more likely to be the extremely long lines in the
>file. If you have emacs-27 or emacs-master, you can try 'M-x
>global-so-long-mode' before visiting the file, which attempts to
>improve Emacs' behaviour in such cases.

Yes, the fact that it is all on one line is likely relevant. I haven't tried installing Emacs 27, but I note that a file 10x as long as the one I attached, consisting of the letter "t" repeated, can be opened and edited without difficulty. My guess is that rendering the escape sequences in the problem file is causing some kind of quadratic complexity.

Frederick

[t (text/troff, attachment)]

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: frederik <at> ofb.net
Cc: Robert Pluim <rpluim <at> gmail.com>, 39658 <at> debbugs.gnu.org
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences 
Date: Tue, 18 Feb 2020 17:02:29 +0100

> My guess is that rendering the escape sequences in the problem file is causing some kind of quadratic complexity. 

It looks like it's the left square brackets ('['). Take them out and it's fast.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: frederik <at> ofb.net
Cc: rpluim <at> gmail.com, 39658 <at> debbugs.gnu.org
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Tue, 18 Feb 2020 18:05:21 +0200

> Date: Tue, 18 Feb 2020 06:15:10 -0800
> From: frederik <at> ofb.net
> Cc: 39658 <at> debbugs.gnu.org
> 
> >The problem is more likely to be the extremely long lines in the
> >file. If you have emacs-27 or emacs-master, you can try 'M-x
> >global-so-long-mode' before visiting the file, which attempts to
> >improve Emacs' behaviour in such cases.
> 
> Yes, the fact that it is all on one line is likely relevant. I haven't tried installing Emacs 27, but I note that a file 10x as long as the one I attached, consisting of the letter "t" repeated, can be opened and edited without difficulty. My guess is that rendering the escape sequences in the problem file is causing some kind of quadratic complexity.

Did you try "M-x find-file-literally RET"?  I'm guessing Emacs tries
to interpret the escape sequences as some variant of ISO-2022 encoding
or something.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: frederik <at> ofb.net
Cc: 39658 <at> debbugs.gnu.org
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Tue, 18 Feb 2020 18:08:55 +0200

> Date: Tue, 18 Feb 2020 05:48:59 -0800
> From: frederik <at> ofb.net
> 
> To reproduce, open the attached file in Emacs, and type C-x C-n. On my system Emacs uses 100% of CPU, indefinitely.

On my system, visiting this file takes 36 sec of CPU time.  Which is
long, but is not indefinitely.

If someone wants to investigate this case, I'd start with visiting the
file after "M-x profiler-start".  Then look at the hot spot(s).

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

From: frederik <at> ofb.net
To: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, 39658 <at> debbugs.gnu.org
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Tue, 18 Feb 2020 08:58:50 -0800

Thank you Mattias for figuring that out, and Eli for being more patient than I.

I think I'll let the professionals handle it from here.

On Tue, Feb 18, 2020 at 05:02:29PM +0100, Mattias Engdegård wrote:
>> My guess is that rendering the escape sequences in the problem file is causing some kind of quadratic complexity.
>
>It looks like it's the left square brackets ('['). Take them out and it's fast.
>

On Tue, Feb 18, 2020 at 06:08:55PM +0200, Eli Zaretskii wrote:
>> Date: Tue, 18 Feb 2020 05:48:59 -0800
>> From: frederik <at> ofb.net
>>
>> To reproduce, open the attached file in Emacs, and type C-x C-n. On my system Emacs uses 100% of CPU, indefinitely.
>
>On my system, visiting this file takes 36 sec of CPU time.  Which is
>long, but is not indefinitely.
>
>If someone wants to investigate this case, I'd start with visiting the
>file after "M-x profiler-start".  Then look at the hot spot(s).
>

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, 39658 <at> debbugs.gnu.org, frederik <at> ofb.net
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Tue, 18 Feb 2020 23:09:06 +0100

On Tue, Feb 18, 2020 at 06:08:55PM +0200, Eli Zaretskii wrote:

> If someone wants to investigate this case, I'd start with visiting the
> file after "M-x profiler-start".  Then look at the hot spot(s).

The profiler didn't show anything, but according to gdb/lldb, there is something going on in the bidi bracket code. Every time I hook on a debugger, the stack is like this:

  * frame #0: 0x000000010dcc41b2 emacs`bidi_find_bracket_pairs(bidi_it=0x00007ffee1fdd610) at bidi.c:2572:12 [opt]
    frame #1: 0x000000010dcc3c1f emacs`bidi_resolve_brackets(bidi_it=0x00007ffee1fdd610) at bidi.c:2856:13 [opt]
    frame #2: 0x000000010dcc1556 emacs`bidi_level_of_next_char [inlined] bidi_resolve_neutral(bidi_it=<unavailable>) at bidi.c:2957:22 [opt]
    frame #3: 0x000000010dcc154e emacs`bidi_level_of_next_char [inlined] bidi_type_of_next_char at bidi.c:3162 [opt]
    frame #4: 0x000000010dcc154e emacs`bidi_level_of_next_char(bidi_it=0x00007ffee1fdd610) at bidi.c:3229 [opt]
    frame #5: 0x000000010dcc0d27 emacs`bidi_move_to_visually_next(bidi_it=0x00007ffee1fdd610) at bidi.c:3422:15 [opt]
    frame #6: 0x000000010dc394af emacs`set_iterator_to_next(it=0x00007ffee1fdcc20, reseat_p=<unavailable>) at xdisp.c:7805:8 [opt]
    frame #7: 0x000000010dc39701 emacs`set_iterator_to_next(it=0x00007ffee1fdcc20, reseat_p=<unavailable>) at xdisp.c:7877:8 [opt]
    frame #8: 0x000000010dc49c5c emacs`display_line(it=<unavailable>, cursor_vpos=<unavailable>) at xdisp.c:23590:2 [opt]
    frame #9: 0x000000010dc47d99 emacs`try_window(window=0x00007fccf791f835, pos=<unavailable>, flags=1) at xdisp.c:19062:11 [opt]
    frame #10: 0x000000010dc71158 emacs`redisplay_window(window=0x00007fccf791f835, just_this_one_p=<unavailable>) at xdisp.c:18480:8 [opt]
    frame #11: 0x000000010dc6f156 emacs`redisplay_window_0(window=<unavailable>) at xdisp.c:16194:5 [opt]
    frame #12: 0x000000010dd64e3f emacs`internal_condition_case_1(bfun=<unavailable>, arg=0x00007fccf791f835, handlers=0x000000010f9df353, hfun=(emacs`redisplay_window_error at xdisp.c:16185)) at eval.c:1379:25 [opt]
    frame #13: 0x000000010dc6e82c emacs`redisplay_windows(window=0x00007fccf791f835) at xdisp.c:16174:4 [opt]
    frame #14: 0x000000010dc45016 emacs`redisplay_internal at xdisp.c:15642:5 [opt]

Test case: perl -le 'print "[" x 60000' > somefile
There seems to be a threshold at around 50000 characters.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: rpluim <at> gmail.com, 39658 <at> debbugs.gnu.org, frederik <at> ofb.net
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Wed, 19 Feb 2020 19:47:42 +0200

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Tue, 18 Feb 2020 23:09:06 +0100
> Cc: Robert Pluim <rpluim <at> gmail.com>, 39658 <at> debbugs.gnu.org, frederik <at> ofb.net
> 
> On Tue, Feb 18, 2020 at 06:08:55PM +0200, Eli Zaretskii wrote:
> 
> > If someone wants to investigate this case, I'd start with visiting the
> > file after "M-x profiler-start".  Then look at the hot spot(s).
> 
> The profiler didn't show anything, but according to gdb/lldb, there is something going on in the bidi bracket code. Every time I hook on a debugger, the stack is like this:
> 
>   * frame #0: 0x000000010dcc41b2 emacs`bidi_find_bracket_pairs(bidi_it=0x00007ffee1fdd610) at bidi.c:2572:12 [opt]
>     frame #1: 0x000000010dcc3c1f emacs`bidi_resolve_brackets(bidi_it=0x00007ffee1fdd610) at bidi.c:2856:13 [opt]

Ah, yes.  Set bidi-inhibit-bpa non-nil, and Bob's your uncle.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, 39658 <at> debbugs.gnu.org, frederik <at> ofb.net
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Thu, 20 Feb 2020 14:36:17 +0100

19 feb. 2020 kl. 18.47 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Ah, yes.  Set bidi-inhibit-bpa non-nil, and Bob's your uncle.

Fine, so how do we proceed from here? I presume that the bug triggers when the bidi cache limit of 50000 elements is reached (or maybe MAX_BPA_STACK). Turn off BPA temporarily, for the current line or paragraph, when this occurs? Or for the entire buffer, on the grounds that it's hardly right-to-left text anyway?

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 39658 <at> debbugs.gnu.org, frederik <at> ofb.net
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Thu, 20 Feb 2020 15:26:07 +0100

[Message part 1 (text/plain, inline)]

On Thu, 20 Feb 2020, 14:36 Mattias Engdegård, <mattiase <at> acm.org> wrote:

> 19 feb. 2020 kl. 18.47 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> > Ah, yes.  Set bidi-inhibit-bpa non-nil, and Bob's your uncle.
>
> Fine, so how do we proceed from here? I presume that the bug triggers when
> the bidi cache limit of 50000 elements is reached (or maybe MAX_BPA_STACK).
> Turn off BPA temporarily, for the current line or paragraph, when this
> occurs? Or for the entire buffer, on the grounds that it's hardly
> right-to-left text anyway?
>


Doesn't so-long-mode turn off bpa?

>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: rpluim <at> gmail.com, 39658 <at> debbugs.gnu.org, frederik <at> ofb.net
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Thu, 20 Feb 2020 16:46:14 +0200

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Thu, 20 Feb 2020 14:36:17 +0100
> Cc: Robert Pluim <rpluim <at> gmail.com>, 39658 <at> debbugs.gnu.org, frederik <at> ofb.net
> 
> 19 feb. 2020 kl. 18.47 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > Ah, yes.  Set bidi-inhibit-bpa non-nil, and Bob's your uncle.
> 
> Fine, so how do we proceed from here? I presume that the bug triggers when the bidi cache limit of 50000 elements is reached (or maybe MAX_BPA_STACK). Turn off BPA temporarily, for the current line or paragraph, when this occurs? Or for the entire buffer, on the grounds that it's hardly right-to-left text anyway?

I think so-long-mode already handles this the best we could do in
general.  I don't know how to solve these pathological cases better,
except advise the user to visit such files literally to begin with.

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 39658 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, frederik <at> ofb.net
Subject: Re: bug#39658: 26.3; can't edit file with terminal escape sequences
Date: Sun, 23 Feb 2020 17:42:32 +1300

On 19/02/20 2:58 am, Robert Pluim wrote:
> The problem is more likely to be the extremely long lines in the
> file. If you have emacs-27 or emacs-master, you can try 'M-x
> global-so-long-mode' before visiting the file, which attempts to
> improve Emacs' behaviour in such cases.

On 21/02/20 3:26 am, Robert Pluim wrote:
> 19 feb. 2020 kl. 18.47 skrev Eli Zaretskii:
> > Ah, yes.  Set bidi-inhibit-bpa non-nil, and Bob's your uncle.
> 
> Doesn't so-long-mode turn off bpa?

Yes it does and so that does provide a solution -- provided that
the original major mode used for the file is one that so-long is
interested in.  The example file here had no file name extension,
nor any magic-mode-alist content, and consequently the default
list of so-long-target-modes was never going to match this.

Perhaps fundamental-mode should be in so-long-target-modes?

Experimentally, that does do the trick in this example; and would
surely cover other similar cases as well.

The big question is whether that might cause more problems than
it solves.  Offhand I think it's probably ok: as far as the major
mode aspects are concerned, so-long-mode is little more than
fundamental-mode, so any file which opened in fundamental-mode
ought to be fine in so-long-mode as well.

I suspect we would also want that large increase to the default
value of so-long-threshold which has previously been discussed,
just on account of the number of different kinds of file which
might now be subject to this, as the heuristic of "programming
code lines are expected to be pretty short" would no longer be
adequate.  I was intending to go ahead with that change in any
case, and IIRC a value of 10,000 seemed to be quite reasonable
in my initial tests.  I was going to do more testing, and still
haven't gotten around to it.


-Phil

Previous Next

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