foldmethod=indent bugs?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

foldmethod=indent bugs?

Evan Laforge

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.

My version is:

VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 11 2008 17:20:43)
Included patches: 1-22
Compiled by [hidden email]
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.

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.

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.

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.

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: foldmethod=indent bugs?

Bram Moolenaar


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 [hidden email]
> 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 -- [hidden email] -- 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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: foldmethod=indent bugs?

Evan Laforge

>> 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.

Ah, I see, I misunderstood the documentation.  Would it make sense to
add a 'put' option?  Or are puts intended to unfold and the current
behaviour is due to a bug?

> Looks like another instance of the first problem.

Indeed, I hope so, then they can both be fixed at once :)

The interesting one is the one only triggered by having a nested open
fold inside.

When I get some time I'll see if these happen with the other fold
methods, and maybe take a look at fold.c if it's not too scary.

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

Ted
Reply | Threaded
Open this post in threaded view
|

Fwd: foldmethod=indent bugs?

Ted
I wrote a vim script that reproduces case 2 of Evan's original bug
report; it is available at this gist: http://gist.github.com/427303

The idea is to run $(vim -u indent_fold_bug.vim) to bring up an
exemplary mis-fold in the top window and to put in the bottom window a
display of foldlevel() for each line in the buffer for each of the few
operations needed to bring about that improper fold state.  Not super
amazing, but it could make things a bit more convenient.

Not sure if this is of any value to people, I mostly just did it to
help narrow down a bit the conditions for this bug.  But since I've
already posted it online, I thought I would make it known to this
list, in case it could be useful to people working on this bug.  I'm
assuming from the fact that no further replies have been made on this
thread that the bug is still open?  Sorry, I'm unfamiliar with the
protocol here; also used to using bug trackers more so than mailing
lists.  Also it appears that patch 7.2.421 is a workaround for this
issue, but maybe there are other problems with folding that it
addresses.  Anyway sorry if I missed a fix for this in a scan of the
recent patches.

The analysis output uses the v:key() variable within a map() call on a
List, so that output will only work with versions of vim >= 7.2.295.
Sorry about that, when I wrote the script I was unaware that this is a
relatively new feature of that function (it doesn't seem to be
documented as such in `eval.txt`, at least not as of 7.2.330).  I
originally wrote the script on a machine with patches up to 7.2.330; I
just tried it on another with patches only up to 7.2.245 and
discovered that the bug is identically reproduced.  These are both
ubuntu versions of the "Huge" vim-gnome package; one is for 10.04 and
the other 9.10.

Anyway, if somebody wants to run the script to test patches on earlier
versions of vim for some reason, let me know and I'll patch the gist,
or you can fork it, or whatever.

I'm also a bit confused at the lack of a "reply to list" option when
viewing the archives; maybe I'm missing a setting or something?

Cheers
-Ted


---------- Forwarded message ----------
From: Evan Laforge <[hidden email]>
Date: Oct 28 2009, 4:22 pm
Subject: foldmethod=indent bugs?
To: vim_dev


>> 4. foldmethod=all seems buggy.  When I turn it on, folds open even
>> when I move through them vertically, and neverfoldeven 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, afoldat the cursor is
> always open.

Ah, I see, I misunderstood the documentation.  Would it make sense to
add a 'put' option?  Or are puts intended to unfold and the current
behaviour is due to a bug?

> Looks like another instance of the first problem.

Indeed, I hope so, then they can both be fixed at once :)

The interesting one is the one only triggered by having a nested
openfoldinside.

When I get some time I'll see if these happen with the otherfold
methods, and maybe take a look atfold.c if it's not too scary.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php