Evan Laforge wrote:

> I hope this is the right place to post this, I couldn't find any bug
> tracker.  I searched in the archives a little but didn't find these
> mentioned, but they have been bugging me for years and years so it may
> have been mentioned long ago... sorry if these are repeats.  Hopefully
> most are symptoms of the same underlying problem.

This is the right place.

> My version is:
> 
> VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 11 2008 17:20:43)
> Included patches: 1-22
> Compiled by [email protected]
> Normal version without GUI.  Features included (+) or not (-):
> 
> But these have been bugging me ever since folding was added so they
> should be visible in just about any extant version.  I see it on both
> linux and OS X.
> 
> There are a few issues, which show up with foldmethod=indent.  I don't
> know if they show up with other methods, but they're easy to
> demonstrate:
> 
> 1. When adding text at the beginning of an open fold, it spontaneously
> folds up.  Say you have:
> 
> a
>     b
>     c
> 
> If you put some unindented text after 'a' and then >> it over, 'b c'
> will fold up.  Likewise if you insert some text; as soon as you hit
> tab the text you are in the middle of editing disappears into a fold.

I see the problem.  I'll add it to the todo list.

> 2. Folds in indent mode also get out of sync with the buffer contents.
> If you
> have
> 
> a
>     b
>     c
> 
> and then append a blank line plus indented d and e, the folds won't
> combine, so you wind up with what should be one fold but is really
> two.  This happens all the time when pasting stuff into functions and
> the result is a function that won't fold up.  I can work around by
> setting foldmethod=indent again or switching to another buffer and
> back, but this seems more like a bug than a feature.

Another one for the todo list.

> 3. More spontaneous folding:
> 
> For this to work, you need an unfolded fold with two different indent levels:
> 
> function = case something of
>     X
>         Y
>     Z
> 
> I insert some text and indent XYZ:
> 
> function
>     | otherwise = case
>         X
>             Y
>         Z
> 
> At this point XYZ folds up on its own.  If I unfold it, and then add a line
> above 'otherwise', it folds up again as soon as I type the first non-indent
> character, even though there's an intervening line.
> 
> The effect is that XYZ continually folds up on its own whenever I
> touch text in its vicinity.

This sounds every much like the same problem as the first one.

> 4. foldmethod=all seems buggy.  When I turn it on, folds open even
> when I move through them vertically, and never fold even when I try to
> close them explicitly.  Setting all the documented foldopen values
> doesn't have this affect, so evidently 'all' is not the same as
> including everything manually.

You mean ":set foldopen=all".  Right, "all" is not the same as adding
all the other ones.  That works as intended, a fold at the cursor is
always open.

> 5. This is something which could be a bug or not, but I think it's
> undesirable in any case:  If you put below a folded region and the put
> text is also indented, it will join the fold, which will stay closed.
> The effect is that the text you put immediately disappears and you
> have to open the fold and hunt for it.  This happens a lot when I put
> a chunk that begins with a couple newlines.  If the newlines are
> already there, i.e. "a\n\tb\n\tc\n\n" and then put "\td", it doesn't
> join the fold.  If the newlines are part of the put, i.e. "a\n  b\n
> c\n" and put "\n  d", then the put text does join the fold.
> 
> I think its inconsistent, and that it's more useful to always open the
> fold on a put.  It might open more than it needs to, but it's
> consistent, simple, and more likely to be right than the current
> situation.

Looks like another instance of the first problem.

-- 
CONCORDE:  Quickly, sir, come this way!
LAUNCELOT: No!  It's not right for my idiom.  I must escape more  ... more ...
CONCORDE:  Dramatically, sir?
LAUNCELOT: Dramatically.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Raspunde prin e-mail lui