Lech Lorens wrote:
> I would appreciate feedback on my modifications a lot and really hope
> for some comments. You might want to follow my test procedure:
>
> Enter the directory with Vim sources. Execute Vim:
> $ vim -p eval.c eval.c eval.c
> :tabdo set fdm=syntax fdc=5 number
> :normal 1gt
> :820
> :normal zO
>
> And then type the following (observe the fold column):
> Ofor (i =
>
> After inserting '(' with the official syntax highlighting file I need to
> wait a few seconds (sic!) before the screen is updated and "i ="
> appears.
On my machine, I had to wait 1 minute and 50 seconds (!) before I
could see "i = " (and Vim was using 100% of the CPU during that
time). That's with Vim-7.2.284 built with -O0 on a Core-2, 1.7Ghz.
> With my modifications of c.vim Vim responds instantaneously
> (again: observe the difference in the fold column).
After applying your patch (c.vim.patch), I could see "i = "
instantaneously.
I normally don't use syntax folding, but if I did, I would most certainly
want to do it with your patch given the major speed up.
> This comes at a cost, however. While in case of the original syntax
> highlighting all the braces from the modification place to the end of
> the file would become highlighted as error, after my modifications only
> braces inside the current block get such highlighting. This is still
> quite visible if you open a parenthesis at line 820, but is not so any
> more if you do it at line 843.
>
> I am ready to accept such a trade-off as I rely very much on
> C-syntax-based folding and recently more and more often have been
> finding myself in situations where I input some code without getting any
> visual feedback from Vim (this happens on my new machine at work, even
> more on my old computer at home). I presume that there are others who
> are bothered by the same problem. Perhaps the behaviour I introduced to
> c.vim could be made into an option like c_no_curly_error or
> c_no_bracket_error.
I would also accept the trade-off, given the dramatic speed up.
> I would like also to describe the (erroneous in my opinion) behaviour of
> Vim I discovered while trying to improve c.vim. The version of c.vim
> that allows the problem to be reproduced can be obtained by applying the
> attached patch c.vim.patch.bad.
I did not check that yet.
Thanks
-- Dominique
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
