Re: more troubles with jsp syntax (correction)
- On Wed, Dec 06, 2000 at 04:51:59PM -0500, Arjona, Ariel wrote:
> Just curious, but why do these syntax coloring problems happen? I've hadYes this will make a serious CPU hit. VIM will highlight using specified syntax
> syntax coloring problems too, but setting minlines to 2500 solved it (with a
> serious CPU hit when I scroll up though).
rules. In a simple situation a single line with a regex can determine proper rule
(Like keywords or strings).
The problems arise when you have multiple lines which encompass one rule. Say for
example you want all strings to be highlighted pink but stings can spawn
multiple lines. And a string is defined as any character between the delimiters
<% and %> So you say the start of the string is <% and the end will be %>
1 Not a string <% Is a
2 String on more
3 than one line %> Not a string
Here everything between <% and %> is a String. Now imagine that a very small
view at the current line. Say line 2. The only way to tell that the characters
on line to are part of the String rule would be to search backwards till it hit
a <% or a %> if it hit a %> then it knows it not inside a String rule. or
visa-versa if it sees a <% it know it is in one.
Now imagine that the text on line 2 spawned about 100 lines. That's 100 lines of
Syntax Vim has to parse through till it get to the line your interested in.
As for the syncing heres more examples. Say for the purpose of this email your
vim screen is one line in height. so you can only view on line at a time. Lets
walk though the logic as we scroll *Down*.
line 1 we see that it begins with <!-- so we know it's a comment till we hit -->
however inside of comments are strings so if we hit a " before the --> we'll
have to handle that as well (See the nesting). Ok. so say we hit the --> at
around line 4. done. Next we see a <% which means were stopping all HTML
rendering and starting ASP. Next we see a string and a number and a variable
then a comment. And finally a %>. That was allot especially if that was like say
That the feel of the VIM logic (Top-down approach) the problems you see is when
you scrolling *Up* In order for the top-down approach to work here the above
process needs to find a place to start. By default this is the top of the
screen but in situations like above where you have nested syntax you need to
sync to something else. (For example a line with <% in it) But to search
backwards every time the person scrolls up the above process needs to be done
again and again. Very CPU incentive the more complex the rules. So VIM uses a
fall off value to stop this (minlines) if it can't find the sync pattern by
minlines above then it stops and renders it as normal. That's what you see. by
increasing minlines to something crazy like 5000 then VIM will search backwards
for a maximum of 5000 line till it hits the sync pattern or not and begin
rendering from there till it gets to the users view. 5000 lines is allot
considering the ASP syntax has about 20 or so rule on it's own not including
rules that's 30 right there which it parses for 5000 lines *Every* time a user
Yes there are alternative ways then the top-down approach but this one provides
the most flexibility that's why VIM can support practically any lexical syntax.
where as most other highlighting editors only support a few and have no room for
customization. Theres a trade off with performance and scalibility/flexibility
here your seeing one of the cons.
When ever this happens to me I just hit page up till it rights it self then page
down where I was. And yeah I know my explanation was long and pointless but I
was board at the time. Had to avoid work somehow :-)
If VIM were a woman, I'd marry her. Slim, organized, helpful and beautiful;
what's not to like?