> > I assumed they were bugs and would be fixed in the next version, but > > they're still there many years later, and I'm finally wondering if > > maybe others don't see them, or maybe they're not considered bugs, or > > maybe I'm doing something wrong (though I don't see how since I just > > :set foldmethod=indent). > > Might be that other people don't see these "behaviours", just because > they are using other methods of folding. I don't know how many people > actually use fdm=indent, Python programmers?
My day-to-day languages are haskell and python, both of which are layout oriented. I also use indent for C and C++ since it works with K&R style and all the code I edit is K&R style. And then makefiles. I also edit indentation oriented outline list type files. I don't use syntax highlighting so I skipped the whole "syntax" part of folding back when I was learning about it... but maybe it's worth a look if it's less buggy. I don't see why it should be, if my syntax is just "look at indent level" since I'm not interested in colors or anything. > You should try this again with > > :set foldopen+=insert > :h 'fdo Ahh, I didn't know about that option, thanks! It does solve my insert problem. > > Put behaviour with folding is also surprising. If you put below a > > folded region and the put text is also indented, it will join the > > fold, which will stay closed. > > I can imagine this is not always annoying. I suppose I too can imagine such a theoretical circumstance, but so far in real life I've hit it quite a lot and it has always been annoying. One wants to see what one just entered, if only to verify that it makes sense in its context :) It makes sense inserting character at a time in insert mode, and it makes sense inserting a bunch with a put. For an example that comes up quite a bit when refactoring, suppose I pull a chunk of code out of a function, then go put it down beneath another definition. The other definition is naturally folded up, and since the chunk of code is still indented, it gets included in the folded function above it, even though there are several lines of vertical whitespace separating them, but only if those empty lines are in the put. In fact, due to this vertical whitespace, the fold can't be easily opened, since horizontal movement doesn't work. On my test just now, zo did work though I seem to recall it not working. The next time I stumble across it I'll try to reproduce that. Anyway, the editor has no way of knowing that the above function is complete and the chunk is incomplete and I'm going to add lines above it, but if it opened on puts the issue wouldn't come up. In addition, we have a weird invisible connection thing going on where putting the empty lines links the text below with the above fold, and putting below existing empty lines doesn't. Yes, the editor has to make a decision about empty lines and including them in the above fold is the right thing, but it should be consistent! > > The effect is that the text you put immediately disappears and you > > have to open the fold and hunt for it. If you enter text into a fold > > with 'insert' it automatically opens, but if you enter text with put > > it doesn't. Shouldn't it open in both cases? > > I don't think so, not in every case you are going to work on text that > you just put. I do think so, just from personal experience. In any case, maybe foldopen could do with a 'put' option. > But in your case, try setting all 'foldopen' options: > :set foldopen=all This seems to have the effect of disabling folding completely. Folds stay folded, but open as soon as I move into them vertically they open, and a subsequent zc does nothing. This seems to contradict the documentation, which says "Note that vertical movements are not here". > > But it's worse than that, if you have an indent which is open, then > > put something which is indented into it, the whole thing will fold up, > > even though it was explicitly unfolded earlier. I.e. in the 'a b c' > > above, type dd on 'c', then jP to put it above 'b', the whole thing > > should fold up. This is really annoying! > > Hmm, might be this is a bug. What I see here (with default 'fdo'): If > the put text becomes the start of the fold, the fold will close. If > text is put below the first line of the fold, the fold will not close. > (text in the buffer and in the register had the same indent). Even if it weren't annoying in practice, it's strange and inconsistent. > > This also happens if you do an undo that results in something being > > added to the open fold: it closes up automatically. > > Let me again point you to 'foldopen' ;) I do have 'undo' in my default foldopen, so evidently it's not working in some case. I can't repro at the moment, but when I see it happen again I'll try to figure out the circumstances that cause it to happen. > Yep, this looks like a bug. If I just insert > > a > b > c > > d > e > > the resulting folds are (after zM ): > > a > +-- 2 lines: b-------------------------------------------------- > > +-- 2 lines: d-------------------------------------------------- > > but it should be one fold: Yeah, that's it. So I guess I have two things to file. I'll go poke on vim.org to see how to do that.... --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
