On Wed, 26 Jul 2006 14:05:45 -0400, "Cory Echols" <[EMAIL PROTECTED]>
wrote:
>> In other words, I would expect vim to continuously evaluate the
>> foldexpr on the current line for every character I typed, and not do
>> anything else until the fold level changed.
>I once wrote a foldexpression that kept track of the number of times
>it was evaluated. I don't remember the exact numbers, but I was
>astounded by the number of times it was executed for each keystroke.
I just tried that, and my suspicions were confirmed. When in insert
mode, any keystroke will cause foldexpr to be evaluated for every line
above the current line.
>> When I open the file, it opens instantly. I can navigate around the
>> file just fine, and open/close folds. It seems to me that there is
>> something strange about the way the foldexpr seems to be constantly
>> reevaluated when I'm typing.
>I'm suprised the file opens so quickly. Opening the file was where my
>expressions were still unacceptably slow. Even so, I'll bet we're
>more tolerant of delays while opening that we are of delays between
>insert-mode keystrokes.
That must be it. I can wait a second or two while the file is being
opened, but waiting a second or two between each keystroke when I'm
writing is too much.
[...]
>I pretty much gave up on the idea of nested folds. I decided that I
>would only fold method bodies at level 1. This gave me lots of
>shortcuts for keywords that only appeared inside method bodies (so my
>expression could return '1' for those lines). I might post my code,
>but it's verbose and very much overkill because it contains many
>functions that I hoped would be useful for more general c# editing.
Well, I think I've found a solution that works for me. It turns out
that what was causing my problems was where vim interpreted a number
following a marker as a fold level. A line like this would mess up my
folds:
int array[16] = {0};
In those cases it's easy enough to insert a space before the 0, but
there are cases where it's not that easy, or not desireable.
What I ended up doing was changing fold.c to not look for a fold level
after a marker, and recompiling. Now everything seems to work great,
and I don't notice any slowdown.
Perhaps there should be an option for not interpreting numbers after a
fold marker as a fold level, but I don't know if this is causing
enough people grief that it would be included. I'm happy with my quick
fix for now.
--
Be seeing you.
