Hello!
I think (well, I'm sure) I found a bug in vim when using
foldmethod=syntax (both FEAT_SYN_HL and FEAT_FOLD are enabled).
BRIEF:
I attached two unified patches that should be applied after
applying all the upstream patches from 7.2.001 to 7.2.315 to
fix the issue (the bug exists in "plain" vim-7.2 without
patches 1-315 as well though).
vim-7.2-fold_o-test.patch - tests whether the bug exists
vim-7.2-fold_o.patch - fixes the issue.
I was unable to create an empty file in the patch (I
probably should read diff's man page) so after applying
fold_o-test patch you should create the empty file
vim72/src/testdir/test70.ok for the new test to pass
successfully.
I set fml=3 in the test patch to break the solutions that
will "fix" the issue without a loop.
Will the fix get into vim upstream patches? :)
DETAILS:
I have a syntax region with ending match "^$" (empty line),
and foldminlines is set to 1 (the default).
If I enter the line matching the starting match and then
press <Enter> without leaving insert mode then a second line
appears which is empty. Since both lines were modified by
pressing <enter> vim checks whether they (both) should have
non-zero foldlevel. Vim thinks that the second line (being
empty) closes the region so both lines get foldlevel=0
(since only the first one should belong to a fold and
1-line folds are disabled with fml=1).
Then I (still without leaving insert mode) enter a character
(for example, a space) making the second line non-empty. Now
it doesn't match the ending region match anymore and the
region is not closed by the second line and vim checks whether
the _modified_ line should have non-zero fold, discovers that
yes, it should, and marks the second line as _starting_ the
fold with foldlevel=1.
If vim look at the first line now it would see it has non-zero
foldlevel as well (since the block contains more than 1 line now)
and understand that it's the first line that should be marked as
starting the fold. But it doesn't look above (it just checks if
the modified (the second) line belongs to a fold by calling
findFold but the fold has just been created and therefore doesn't
appear in the array findFold acts on).
The similar issue appears for more than two lines if foldminlines
greater than 1.
The issue doesn't appear if one enters a non-zero first line and
then (having left insert mode) breaks it in the middle with i<enter>
because in this case vim will check both modified lines and the
second line isn't empty, so vim understands the fold should be
started at the first line.
--
Vladimir
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
diff -Naur vim72.orig/src/fold.c vim72/src/fold.c
--- vim72.orig/src/fold.c 2009-12-07 23:38:53.000000000 +0300
+++ vim72/src/fold.c 2009-12-07 23:40:29.000000000 +0300
@@ -2254,6 +2254,17 @@
if (fline.lvl >= 0)
break;
}
+
+ if (foldlevelSyntax == getlevel)
+ {
+ int lvl = fline.lvl;
+ while (!got_int && fline.lnum > 0 && (!fline.start || fline.lvl != lvl))
+ {
+ lvl = fline.lvl;
+ fline.lnum--;
+ getlevel(&fline);
+ }
+ }
}
/*
diff -Naur vim72.orig/src/testdir/Makefile vim72/src/testdir/Makefile
--- vim72.orig/src/testdir/Makefile 2009-12-08 19:02:45.000000000 +0300
+++ vim72/src/testdir/Makefile 2009-12-08 18:16:56.000000000 +0300
@@ -23,7 +23,7 @@
test54.out test55.out test56.out test57.out test58.out \
test59.out test60.out test61.out test62.out test63.out \
test64.out test65.out test66.out test67.out test68.out \
- test69.out
+ test69.out test70.out
SCRIPTS_GUI = test16.out
diff -Naur vim72.orig/src/testdir/test70.in vim72/src/testdir/test70.in
--- vim72.orig/src/testdir/test70.in 1970-01-01 03:00:00.000000000 +0300
+++ vim72/src/testdir/test70.in 2009-12-08 18:55:11.000000000 +0300
@@ -0,0 +1,13 @@
+Test for a syntax fold being created correctly when an ending region match becomes not ending
+
+STARTTEST
+:%d
+:sy region r start="^s" end="^$" fold
+:se fdm=syntax
+:se fml=3
+ishould be deleted
+ should be deleted
+ should be deleted
+ should and will be deletedzcGdd:wq test.out
+ENDTEST
+
