I'll attach a .rst file that seems to cause the problem. Oddly enough, the problem occurs when I add a '-' in the middle of a bunch of '=' characters (which is a common typo of mine when extending a table heading). bmb24 phenix_test > emerge info Portage 2.0.53 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.6-r2, 2.6.14-gentoo-r2 x86_64) ================================================================= System uname: 2.6.14-gentoo-r2 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 ccache version 2.3 [disabled] dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig cvs distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.utf8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X alsa audiofile avi berkdb bitmap-fonts bzip2 cairo cdr crypt cups curl eds emboss encode esd ethereal exif expat fam ffmpeg foomaticdb fortran gd gdbm gif glut gmp gnome gstreamer gtk gtk2 idn imagemagick imlib ipv6 java jpeg kde lcms libwww lua lzw lzw-tiff mad mailwrapper mng motif mp3 mpeg ncurses nls ogg opengl pam pcre pdflib perl png python qt quicktime readline recode ruby sdl spell ssl tcpd tetex tiff truetype truetype-fonts type1-fonts udev usb userlocales xine xml2 xpm xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Created attachment 78239 [details] gridding.rst
Okay. It doesn't actually hang. It just takes a reaaallllly long time to do the highlighting. You can see this if you move the duff - further to the left. Given long enough it'll eventually finish the syntax and resume. On column 28 it takes several seconds. On column 29 it takes tens of seconds. On column 30 it takes nearly a minute. Next step: find the regex that's causing it.
syntax/rst.vim:35 That's a really nasty regex... Can get the same result via: :echo matchstr("=========== ============= =================-==============", '^\s*\%(=\+\s\+\)\%(=\+\s*\)\+$') vim6 does this too, so it's not a regression. So... We could change it to use this (icky) regex: start='^\n\%(\s*\)\@>\%(\%(=\+\)\@>\%(\s\+\)\@>\)\%(\%(\%(=\+\)\@>\%(\s*\)\@>\)\+\)\@>$' The same thing will need to be done for rstSimpleTableLines etc. too. Pretty nasty.
(In reply to comment #3) > syntax/rst.vim:35 > > That's a really nasty regex... > > Can get the same result via: > > :echo matchstr("=========== ============= =================-==============", > '^\s*\%(=\+\s\+\)\%(=\+\s*\)\+$') > > vim6 does this too, so it's not a regression. > > So... We could change it to use this (icky) regex: > > start='^\n\%(\s*\)\@>\%(\%(=\+\)\@>\%(\s\+\)\@>\)\%(\%(\%(=\+\)\@>\%(\s*\)\@>\)\+\)\@>$' > > The same thing will need to be done for rstSimpleTableLines etc. too. > > Pretty nasty. Well, thanks to the wonders of backtracking NFAs, yes, my regex is very slow, and yours is of course slow as it is so complex. I was wondering if I should remove the whole table-matching syntax-code. I think it's too complex as it is, gives so-so results, and just makes tables a bit too flourescent. So, what do you say, can we just drop the /rst\(Simple\)\=Table\(Lines\)\=/? Thanks for spotting this, by the way. nikolai
Hrm. In theory adding the no backtracks marks shouldn't slow things down (beyond a very slight increase in parse time). Is this not the case? If they're introducing substantial overhead we might have found a bug in the regex engine.
(In reply to comment #5) > Hrm. In theory adding the no backtracks marks shouldn't slow things down > (beyond a very slight increase in parse time). Is this not the case? If they're > introducing substantial overhead we might have found a bug in the regex engine. > Oh! Of course! Sorry, I misread the regex. Still, I think that these highlightings ar too complex and add too little value to be included. What's your thoughts on that?
Aww, I think they're pretty.
Is this bug still a problem? I'm not able to reproduce it myself.
Can't reproduce, so I'm resolving the bug. Feel free to yell at me if it's still a problem. Maybe somebody fixed this in the interim and didn't note it here?
