On 7/26/06, Thore B. Karlsen <[EMAIL PROTECTED]> wrote:
>> set foldexpr=GetFoldLevel() >> >> function! GetFoldLevel() >> let line_text = getline(v:lnum) >> >> let left_idx = (stridx(line_text, '{') >= 0) >> let right_idx = (stridx(line_text, '}') >= 0) >> >> if left_idx >> if ! right_idx >> return 'a1' >> endif >> elseif right_idx >> return 's1' >> endif >> >> return '=' >> endfunctionI spoke too soon. I tested it on another file that is 2500 lines long, and it is still unbearably slow. It gets worse towards the end of the file, where it can still take seconds for characters to show up when I type them. I think I'll have to fire up vim in a profiler to see what is causing this slowness, because if this system can compress dozens of channels of video in realtime without breaking a sweat it seems strange that inserting a character in a smallish text file would be a problem.
Use of return values like 'a1', 's1' and '=' in a fold expression will cause significant slowdown. This is because vim has to recursively evaluate the fold expression for many lines every time the folding is recalculated. Since your expression returns nothing other than these particular values, it probably has to run the expression on *every* line in your file. I tried experimenting with folding expressions for c# a while back. I found that I had to return real number values for as many lines as possible. (Even when it wasn't necessary for correctness). This gave absolute fold levels for many lines and limited the recursive evaluation that vim had to use in situations where I had to return an 'a1', 's1' or '='. This was the only way I could get acceptable performance.
