Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syntax highlighting breaks for big file after jump or search #2790

Closed
machsix opened this issue Apr 8, 2018 · 26 comments

Comments

Projects
None yet
10 participants
@machsix
Copy link

commented Apr 8, 2018

This issue was already reported by somebody else on vim-use mailist. In short words, if a file is very large (more than 10k lines), the syntax highlighting will break if I use :linenumber or search to jump to another line. But it won't break if I keep using PageDown to jump. I need to revoke :syntax on to get highlighting back.

Minium vimrc to reproduce:

syntax enable
filetype plugin on

Even if I add set synmaxcol=0 to the file, the problem will occur. Vim version info:

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Feb 26 2018 23:02:12)
Included patches: 1-1542
Compiled by Arch Linux
Huge version without GUI.  Features included (+) or not (-):
+acl               +farsi             +mouse_sgr         -tag_any_white
+arabic            +file_in_path      -mouse_sysmouse    +tcl/dyn
+autocmd           +find_in_path      +mouse_urxvt       +termguicolors
-autoservername    +float             +mouse_xterm       +terminal
-balloon_eval      +folding           +multi_byte        +terminfo
+balloon_eval_term -footer            +multi_lang        +termresponse
-browse            +fork()            -mzscheme          +textobjects
++builtin_terms    +gettext           +netbeans_intg     +timers
+byte_offset       -hangul_input      +num64             +title
+channel           +iconv             +packages          -toolbar
+cindent           +insert_expand     +path_extra        +user_commands
-clientserver      +job               +perl/dyn          +vertsplit
-clipboard         +jumplist          +persistent_undo   +virtualedit
+cmdline_compl     +keymap            +postscript        +visual
+cmdline_hist      +lambda            +printer           +visualextra
+cmdline_info      +langmap           +profile           +viminfo
+comments          +libcall           +python/dyn        +vreplace
+conceal           +linebreak         +python3/dyn       +wildignore
+cryptv            +lispindent        +quickfix          +wildmenu
+cscope            +listcmds          +reltime           +windows
+cursorbind        +localmap          +rightleft         +writebackup
+cursorshape       +lua/dyn           +ruby/dyn          -X11
+dialog_con        +menu              +scrollbind        -xfontset
+diff              +mksession         +signs             -xim
+digraphs          +modify_fname      +smartindent       -xpm
-dnd               +mouse             +startuptime       -xsmp
-ebcdic            -mouseshape        +statusline        -xterm_clipboard
+emacs_tags        +mouse_dec         -sun_workshop      -xterm_save
+eval              +mouse_gpm         +syntax            
+ex_extra          -mouse_jsbterm     +tag_binary        
+extra_search      +mouse_netterm     +tag_old_static    
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -D_FORTIFY_SOURCE=2  -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linking: gcc   -L. -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.26/core_perl/CORE  -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -L/usr/local/lib -Wl,--as-needed -o vim        -lm -ltinfo -lelf -lnsl    -lacl -lattr -lgpm -ldl   -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.26/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -L/usr/local/lib  -L/usr/lib/perl5/5.26/core_perl/CORE -lperl -lpthread -lnsl -ldl -lm -lcrypt -lutil -lc   -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lieee -lm     

Example of "large file" is provided in the thread vim-use mailist. BTW: this issue doesn't exist in vim74. Thanks for your help!

@h-east

This comment has been minimized.

Copy link

commented Apr 8, 2018

Hi,

See the document in Vim.
:h :syn-sync
:h :syn-sync-third

Is the issue resolved with the following settings?

:syntax sync minlines=10000
@machsix

This comment has been minimized.

Copy link
Author

commented Apr 8, 2018

No. It doesn't. If I use G to directly jump from start of file to the end of file, syntax highlighting still breaks. Interestingly, I found if I do :20000, :40000 then G, syntax highlighting won't break.

@h-east

This comment has been minimized.

Copy link

commented Apr 8, 2018

Is it possible to upload the file where the problem occurs to Gist etc?

@machsix

This comment has been minimized.

Copy link
Author

commented Apr 8, 2018

It's uploaded to here

@chrisbra

This comment has been minimized.

Copy link
Member

commented Apr 9, 2018

Does this only happen for asciidoc files? It looks like a problem of the syntax file. Here is the output of :syntime after doing the G jump (and it noticeably takes a couple of seconds until the file is redrawn with syntax on correctly:

  TOTAL      ANZAHL MATCH   LANGSAMST   DURCHSCHN NAME               MUSTER
  0.200709   34712  0       0.005521    0.000006  asciidocTriplePlusPassthrough \\\@<!\(^\|[^0-9a-zA-Z$]\)\@<=+++..\{-}\(+++\([^0-9a-zA-Z$]\|$\)\@=\|^$\)
  0.135432   34712  0       0.000061    0.000004  asciidocDoubleDollarPassthrough \\\@<!\(^\|[^0-9a-zA-Z$]\)\@<=\$\$..\{-}\(\$\$\([^0-9a-zA-Z$]\|$\)\@=\|^$\)
  0.088924   34712  0       0.000183    0.000002  asciidocMacroAttributes [\\0-9a-zA-Z]\@<!\w\(\w\|-\)*:\S\{-}\[
  0.080844   34712  0       0.000268    0.000002  asciidocMacroAttributes \(\\\@<!{\w\(\w\|[-,+]\)*\([=!@#$%?:].*\)\?}\)\@<=\S\{-}\[
  0.063143   34712  0       0.000039    0.000002  asciidocEmail      [\\.:]\@<!\(\<\|<\)\w\(\w\|[.-]\)*@\(\w\|[.-]\)*\w>\?[0-9A-Za-z_]\@!
  0.041724   34712  0       0.000043    0.000001  asciidocURL        \\\@<!\<\(http\|https\|ftp\|file\|irc\):\/\/[^| \t]*\(\w\|\/\)
  0.040988   34712  0       0.000051    0.000001  asciidocLiteralParagraph \(\%^\|\_^\s*\n\)\@<=\s\+\S\+
  0.039542   34712  0       0.000042    0.000001  asciidocList       ^\s*\(\(\d\+\.\)\|\.\{1,5}\|\(\a\.\)\|\([ivxIVX]\+)\)\)\s\+
  0.038525   34712  0       0.002541    0.000001  asciidocList       ^\s*\(-\|\*\{1,5}\)\s
  0.038258   34712  0       0.000066    0.000001  asciidocListNumber ^\s*\zs\(\(\d\+\.\)\|\.\{1,5}\|\(\a\.\)\|\([ivxIVX]\+)\)\)\ze\s\+
  0.037079   34712  0       0.000032    0.000001  asciidocQuotedDoubleQuoted \(^\|[| \t([.,=\]]\)\@<=``\([` \n\t]\)\@!\(.\|\n\(\s*\n\)\@!\)\{-}\S\(''\([| \t)[\],.?!;:=]\|$\)\@=\)
  0.036827   34712  0       0.000096    0.000001  asciidocList       .\+\(:\{2,4}\|;;\)$
  0.036740   34712  0       0.000810    0.000001  asciidocQuotedBold \(^\|[| \t([.,=\]]\)\@<=\*\([* \n\t]\)\@!\(.\|\n\(\s*\n\)\@!\)\{-}\S\(\*\([| \t)[\],.?!;:=]\|$\)\@=\)
  0.036528   34712  0       0.001614    0.000001  asciidocQuotedEmphasized \(^\|[| \t([.,=\]]\)\@<=_\([_ \n\t]\)\@!\(.\|\n\(\s*\n\)\@!\)\{-}\S\(_\([| \t)[\],.?!;:=]\|$\)\@=\)
  0.036405   34712  0       0.000127    0.000001  asciidocQuotedAttributeList \\\@<!\[[a-zA-Z0-9_-][a-zA-Z0-9 _-]*\][+_'`#*]\@=
  0.036352   34712  0       0.000189    0.000001  asciidocQuotedSingleQuoted \(^\|[| \t([.,=\]]\)\@<=`\([` \n\t]\)\@!\([^`]\|\n\(\s*\n\)\@!\)\{-}[^` \t]\('\([| \t)[\],.?!;:=]\|$\
  0.035757   34712  0       0.000042    0.000001  asciidocMacroAttributes \\\@<!\[\{3}\(\w\|-\|_\|:\|\.\)\+
  0.035313   34712  0       0.000034    0.000001  asciidocMacroAttributes \\\@<!<<"\{-}\(\w\|-\|_\|:\|\.\)\+"\?,\?
  0.035204   34712  0       0.000029    0.000001  asciidocAttributeRef \\\@<!{\w\(\w\|[-,+]\)*\([=!@#$%?:].*\)\?}
  0.035166   49658  0       0.000097    0.000000  asciidocCallout    \\\@<!<\d\{1,2}>
  0.034688   34712  0       0.000076    0.000001  asciidocQuotedEmphasized2 \(^\|[| \t([.,=\]]\)\@<='\([' \n\t]\)\@!\(.\|\n\(\s*\n\)\@!\)\{-}\S\('\([| \t)[\],.?!;:=]\|$\)\@=\)
  0.034575   34712  0       0.000044    0.000001  asciidocMacroAttributes \\\@<!\[\{2}\(\w\|-\|_\|:\|\.\)\+,\?
  0.034524   34712  0       0.000042    0.000001  asciidocQuotedUnconstrainedMonospaced [\\+]\@<!++\S\_.\{-}\(++\|\n\s*\n\)
  0.034100   34712  0       0.000136    0.000001  asciidocQuotedMonospaced2 \(^\|[| \t([.,=\]]\)\@<=`\([` \n\t]\)\@!\(.\|\n\(\s*\n\)\@!\)\{-}\S\(`\([| \t)[\],.?!;:=]\|$\)\@=\)
  0.033803   34712  0       0.000076    0.000001  asciidocQuotedMonospaced \(^\|[| \t([.,=\]]\)\@<=+\([+ \n\t]\)\@!\(.\|\n\(\s*\n\)\@!\)\{-}\S\(+\([| \t)[\],.?!;:=]\|$\)\@=\)
  0.031844   34712  0       0.000135    0.000001  asciidocTable_OLD  ^\([`.']\d*[-~_]*\)\+[-~_]\+\d*$
  0.029696   34712  0       0.000038    0.000001  asciidocAdmonition ^\u\{3,15}:\(\s\+.*\)\@=
  0.026437   34712  0       0.000091    0.000001  asciidocHLabel     \(::\|;;\)\(\s\+\|\\$\)
  0.026341   34712  0       0.000041    0.000001  asciidocListLabel  \(:\{2,4}\|;;\)$
  0.024397   34712  0       0.000035    0.000000  asciidocQuotedUnconstrainedBold \\\@<!\*\*\S\_.\{-}\(\*\*\|\n\s*\n\)
  0.023728   34712  0       0.000082    0.000000  asciidocMacroAttributes \\\@<!(\{2,3}
  0.023711   34712  0       0.000307    0.000000  asciidocEntityRef  \\\@<!&[#a-zA-Z]\S\{-};
  0.023680   34712  0       0.000059    0.000000  asciidocQuotedSuperscript \\\@<!\^\S\_.\{-}\(\^\|\n\s*\n\)
  0.023046   34712  0       0.000029    0.000000  asciidocQuotedUnconstrainedEmphasized \\\@<!__\S\_.\{-}\(__\|\n\s*\n\)
  0.022620   34712  0       0.000072    0.000000  asciidocListBullet ^\s*\zs\(-\|\*\{1,5}\)\ze\s
  0.022468   34712  0       0.000041    0.000000  asciidocLineBreak  [ \t]+$
  0.022089   34712  9888    0.000042    0.000000  asciidocOneLineTitle ^=\{1,5}\s\+\S.*$
  0.021861   34712  0       0.000028    0.000000  asciidocQuotedSubscript \\\@<!\~\S\_.\{-}\(\~\|\n\s*\n\)
  0.019946   34712  34712   0.000794    0.000000  asciidocHLabel     ^\s*
  0.016853   34712  34712   0.000079    0.000000  asciidocListLabel  ^\s*
  0.012947   34712  0       0.000029    0.000000  asciidocTwoLineTitle ^[^. +/].*[^.]\n[-=~^+]\{3,}$
  0.010380   34712  0       0.000060    0.000000  asciidocFilterBlock ^\w*\~\{4,}$
  0.008155   34712  0       0.000028    0.000000  asciidocOpenBlockDelimiter ^--$
  0.006011   34712  0       0.000042    0.000000  asciidocPagebreak  ^<\{3,}$
  0.004880   34712  7473    0.000021    0.000000  asciidocListingBlock ^-\{4,}$
  0.004618   34712  0       0.000030    0.000000  asciidocPassthroughBlock ^+\{4,}$
  0.004595   34712  0       0.000028    0.000000  asciidocExampleBlockDelimiter ^=\{4,}$
  0.004416   34712  0       0.000031    0.000000  asciidocSidebarDelimiter ^*\{4,}$
  0.004339   34712  0       0.000027    0.000000  asciidocRuler      ^'\{3,}$
  0.004324   34712  0       0.000026    0.000000  asciidocCommentBlock ^/\{4,}$
  0.004167   34712  0       0.000027    0.000000  asciidocQuoteBlockDelimiter ^_\{4,}$
  0.004044   22419  7473    0.000023    0.000000  asciidocListingBlock ^-\{4,}$
  0.003801   34712  0       0.000027    0.000000  asciidocLiteralBlock ^\.\{4,}$
  0.003168   34712  0       0.000026    0.000000  asciidocBlockTitle ^\.[^. \t].*[^-~_]$
  0.003144   34712  0       0.000025    0.000000  asciidocCommentLine ^//\([^/].*\|\)$
  0.003084   34712  0       0.000026    0.000000  asciidocListContinuation ^+$
  0.003006   34712  0       0.000027    0.000000  asciidocAttributeEntry ^:\w
  0.002830   34712  0       0.000019    0.000000  asciidocIdMarker   ^\$Id:\s
  0.002779   34712  0       0.000029    0.000000  asciidocBackslash  \\
  0.002683   34712  0       0.000053    0.000000  asciidocAttributeList ^\[[^[ \t].*\]$
  0.002393   34712  0       0.000021    0.000000  asciidocTableBlock2 ^!=\{3,}$
  0.002110   34712  0       0.000027    0.000000  asciidocTableBlock ^|=\{3,}$

  1.761739   2154797

You might try to contact the syntax script maintainer and see if he knows of any settings to have it perform better.

@machsix

This comment has been minimized.

Copy link
Author

commented Apr 17, 2018

This problem doesn't only happen for asciidoc file. Fortran code has the same problem. I uploaded a sample to here. With synctime report, I found fortranConstructName took more than 1s. If I set fortran_more_precise=0, the the issue would disappear. Another workaround is to set re=1.
But I didn't find the same problem with vim7.4

@chrisbra

This comment has been minimized.

Copy link
Member

commented Apr 17, 2018

well, as said before, try contacting the syntax script maintainer and see if he has an idea how to improve the regexes there.

@leycec

This comment has been minimized.

Copy link

commented May 10, 2018

Consider re-opening this issue. At python-mode/python-mode#890, I voluminously document a similar issue. Under prior versions of Vim, syntax highlighting could always be restored at any arbitrary point of any arbitrarily large file by issuing some combination of the :syn sync fromstart, :syn sync minlines=[insert small integer here], and/or :syn on Ex commands.

Under Vim 8.0, however, none of these Ex commands actually do anything when editing large files; syntax highlighting remains fundamentally broken. Something appears to have gone awry in the Vim codebase itself – regardless of the time and space complexity of regular expressions in third-party syntax scripts. At the very least, Vim should supply an explicit warning, error, or other :message as to why exactly it's refusing to perform syntax highlighting in a seemingly non-deterministic manner for large files.

@wanchaol

This comment has been minimized.

Copy link

commented Jun 27, 2018

same here. Please consider reopen it and try to fix this as this is really a bad experience for vim user.

@h-east

This comment has been minimized.

Copy link

commented Jun 27, 2018

Please tell me the setting value of your 'redrawtime'.

    :set redrawtime?

Even if you set 'redrawtime' to 10000, will your problem occur?

    :set redrawtime=10000
@wanchaol

This comment has been minimized.

Copy link

commented Jun 27, 2018

Thanks for suggesting the fix. I did another hack with

syntax sync fromstart

it starts working, although it's a little bit slow. I will also try your suggestion when it breaks again.

@tlathm

This comment has been minimized.

Copy link

commented Jul 9, 2018

I ran into this editing large php files after updating from 8.0.0386 to 8.0.1298 under Gentoo, and can actually reproduce it reliably.

Oddly enough, attempting ":syntax sync fromstart" causes a failure with "Vim: Caught deadly signal SEGV" for me. However, as far as I can tell so far, changing that redrawtime from the default of 2000 to 10000 as suggested by h-east appears to correct this. I'll post back if I find otherwise, but so far so good.

@leycec

This comment has been minimized.

Copy link

commented Jul 19, 2018

Unlike wanchaol but like tlathm, :syntax sync fromstart fails to suffice (as previously noted). Thankfully, like both h-east and tlathm, :set redrawtime=10000 does appear to suffice. And, like tlathm, I'm also on Gentoo – which seems more than a little suspicious, frankly. Kudos for the zany workaround, @h-east. (My brainpan is now exploding.)

Can you offer any deep insight as to why this only recently became an issue? Would it be feasible for Vim itself to dynamically increase this setting as a function of buffer size, thus automatically granting larger files more leeway with respect to syntax highlighting redraws than smaller files? Alternately, would globally bumping the default from its current value of 2000 to 10000 be feasible?

@h-east

This comment has been minimized.

Copy link

commented Jul 19, 2018

This behavior (When the syntax highlight processing exceeds 'rederawtime', it is disabled) was added in Vim 8.0.0647 on 18 Jun 2017.
And bugfixed Vim 8.0.1133 on 22 Sep 2017.

Here is a document. :h 'rdt

'redrawtime' 'rdt'	number	(default 2000)
	[...]
	For syntax highlighting the time applies per window.  When over the
	limit syntax highlighting is disabled until |CTRL-L| is used.
	This is used to avoid that Vim hangs when using a very complicated
	pattern.

I think that it rarely exceeds the default value of 'redrawtime' 2000 msec probably if the specifications of the PC in the last 5 or 6 years.
It happens with huge file wether uses PC specifications is low or very complicated pattern in syntax highlighting.

would globally bumping the default from its current value of 2000 to 10000 be feasible?

I don't think it's necessary.
If you want to ensure syntax highlighting, always set a large value for 'redrawtime'.

@leycec

This comment has been minimized.

Copy link

commented Jul 20, 2018

It happens with huge file wether uses PC specifications is low

The Raspberry Pi is a thing. Just sayin'. 🤷‍♂

My machine is tolerably recent, but I still hit this issue. It's a bit disconcerting that Vim now silently fails in edge cases with no discernable error reporting. Which is the principal issue for me.

I'm quite O.K. with shifting the burden of resolution onto the end user by requiring that the default redrawtime be manually overriden. That's fine. This is Vim, after all. We're all adult grognards here. What I'm not so O.K. with is Vim's failure to either:

  • Emit messages on syntax highlighting failures.
  • Automatically recover from the first syntax highlighting failure. Currently, the first syntax highlighting failure that exceeds the default redrawtime causes syntax highlighting to permanently fail for the current buffer. That's bad. Ideally, Vim should be able to repair this situation on its own (e.g., by scheduling a subsequent redraw, perhaps with a redrawtime temporarily set to a larger threshold).

Isn't there something we (by whom I mean: someone not me) can do to at least inform users when this sort of catastrophic event occurs? Silent-but-deadly failures are the worst possible failures.

or very complicated pattern in syntax highlighting.

Right. In my case, python-mode appears to be the culprit. I've yet to notice syntax highlighting failures with other modes. That said, @tlathm appears to hit this in some sort of PHP mode as well. whatevas

I don't think it's necessary.

Fair enough. Laziness is a virtue that I live by. That said, underpowered systems and/or complex regexes aren't the only culprits here. Even a high-powered system under sufficient CPU load will probably choke in similar ways when highlighting sufficiently large buffers.

This might be more widespread of an issue than you suspect.

leycec added a commit to leycec/vimrc that referenced this issue Jul 20, 2018

Large file syntax highlighting kludge.
Large file syntax highlighting appears to be fundamentally broken as of
Vim >= 8.0.0647. As a temporary solution, we adopt the horrible (but
unavoidable) kludge recommended by Vim developers of permanently
increasing the "redrawtime" (i.e., maximum number of milliseconds Vim
permits itself to syntax highlight large buffers in) from the
insufficient default of 2,000 milliseconds to the substantially larger
(but equally arbitrary) value of 10,000 milliseconds.

Yes, this is atrocious. For further details, see ongoing discussion at:
     vim/vim#2790

leycec added a commit to leycec/vimrc that referenced this issue Jul 20, 2018

Large file syntax highlighting kludge.
Large file syntax highlighting appears to be fundamentally broken as of
Vim >= 8.0.0647. As a temporary solution, we adopt the horrible (but
unavoidable) kludge recommended by Vim developers of permanently
increasing the "redrawtime" (i.e., maximum number of milliseconds Vim
permits itself to syntax highlight large buffers in) from the
insufficient default of 2,000 milliseconds to the substantially larger
(but equally arbitrary) value of 10,000 milliseconds.

Yes, this is atrocious. For further details, see ongoing discussion at:
     vim/vim#2790
@chrisbra

This comment has been minimized.

Copy link
Member

commented Jul 20, 2018

Well the warning could happen often. But it might be a good idea to warn, when the syntax pattern timed out. So here is a patch, that warns if the verbose setting is larger 5 chrisbra@fab78fa

@brammool

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2018

I suppose that people who read the hint to set 'verbose' to 5 are already rare. Let's just give a message when disabling syntax highlighting. We'll have to see if this is too annoying.

@chrisbra

This comment has been minimized.

Copy link
Member

commented Jul 20, 2018

Hm, I suppose that works as well. However now there is no indication, which pattern caused this. I guess one has to check the output of :syntime and guess. BTW: does :syntime work correctly once syn_win->w_s->b_syn_slow has been set?

@brammool

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2018

@machsix

This comment has been minimized.

Copy link
Author

commented Jul 23, 2018

To summarize the issue, is it fair to say that it is caused by

  • Large size of file
  • Syntax highlighting takes more time than the setting of redrawtime
    The solution is:
  • Set redrawtime to a large value like 10000
  • Or run syntax sync fromstart when the highlighting breaks
@h-east

This comment has been minimized.

Copy link

commented Jul 23, 2018

8.1.0198

From this version, the following message is output when the syntax highlight becomes disabled in excess of 'redrawtime'.

'redrawtime' exceeded, syntax highlighting disabled
@tlathm

This comment has been minimized.

Copy link

commented Jul 25, 2018

Just installed 8.1.0198 under Gentoo and tested that new warning. Excellent...tells you exactly what to change. Thanks!

@leycec

This comment has been minimized.

Copy link

commented Jul 26, 2018

Thanks for the prompt attention, @brammool. The new warning is perfect in its succinct perfection – referencing the newly introduced redrawtime setting for the uninitiated (i.e., me).

Party confections for all! 🎉

@Tao-Quixote

This comment has been minimized.

Copy link

commented Sep 7, 2018

This also happens in Version 8.1. I'm a FE developer, the file are as follows:

<template lang="jade">
  div.cntr
    ...
</template>

<style lang="stylus">
  .cntr
    color: red;
    ....
</style>

<script>
  export default {
    props: {
      ...
    },
    methods: {
      function foo () {}
    }
  }
</script>

This file has 906 lines. When i scroll down by <Ctrl-D> or <Ctrl-F>, the syntax will broke, not always, but often. I followed the instruction of @leycec & @wanchaol by doing syntax sync fromstart, then the syntax is back.

I don't know how this works, but the hack actually fix the problem. If anyone know, pls tell me. And I hope that this hack could help someone has the same problem.

@nkaretnikov

This comment has been minimized.

Copy link

commented Mar 13, 2019

FWIW: bumped into this while editing a large Python file (more than 10k lines).
set re=1, as suggested above, appears to fix this.
VIM - Vi IMproved 8.1 (2018 May 18, compiled Mar 11 2019 08:36:40)
macOS version

@sbromberger

This comment has been minimized.

Copy link

commented Apr 4, 2019

I bumped into this today when editing a 2500-line Julia test file (lots of syntax highlighting). set redrawtime=10000 seems to have fixed things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.