Join GitHub today
Feature Request: cache syntax highlighting to improve 'relativenumber' scroll performance #1735
Hello Vim team,
Basically the issue boils down to syntax highlighting needing to be calculated for every visible line when scrolling up or down with relativenumber enabled. The more lines visible and the slower the host CPU the worse the performance hit especially for languages with complex syntax highlighters such as Ruby.
In issue #282 Bram said this (Dec 2015):
I suspect, if implemented, that this suggestion indeed would greatly help scroll performance for those of us who enable relativenumber. A new setting possibly? cachesyntax?
I leave it to the Vim masters to either: do this, or not do this, or schedule later, or close if too hard.
referenced this issue
May 30, 2017
Ok, I don't know the internals of cursorline or vim's syntax highlighting, but it seems to me that it should be possible to completely separate cursorline highlighting from syntax highlighting?
Usually, the cursorline just changes the background colour for the current line. So...
I don't understand why the entire screen's syntax highlighting needs to be recalculated because the background colour of one line gets toggled.
added a commit
Jan 18, 2018
If you comb through the various postings about this issue across the internet these suggestions come up frequently as a fix:
However these I suspect are actually just fixing people's issues with 3rd party plugins.
The real fix for this is:
Hopefully this helps others as it took me some time to find the culprit. Cheers.
I agree with:
set ttyfast set regexpengine=1
I also recommend this setting:
Only syntax highlight the first 200 chars of a line. Very long lines are a killer with
The Ruby syntax highlighter contains hundreds of regexps, multiple by the number of visible lines can equal very bad scroll performance with