1

My current workflow looks something like this:

  1. Open a file in different splits, each split showing a different section
  2. Make appropriate edits in each split
  3. :wq from the split after editing
  4. Repeat as often as necessary

This often ends up breaking the folds structure, as I find that on reopening the file after a series of edits, the folds are no longer where they are/were supposed to be. On one occasion it was so bad I had to delete all the folds and re-fold an entire 2000 line file. I would really like to avoid getting into that sort of annoyance again.

What causes this and how do I preserve the folds?

  • 2
    What is your foldmethod? – Matt Sep 6 at 11:49
  • 2
    So you don't supply any file name for mkview/loadview? The generated name depends on the buffer name, so with the splits they will overwrite one another. You need to supply a number, like mkview 1 / loadview 1, mkview 2 / loadview 2 etc. – Matt Sep 6 at 12:38
  • 1
    You still have to find a way to trace counters. The things would be much easier if you could live with automatic folds only. – Matt Sep 6 at 13:26
  • 1
    @Matt You are right, doing that ^ fixed the problem. Thanks a ton! – Yogesch Sep 6 at 13:26
  • 1
    @filbranden I prefer if @Yogesch writes what he thinks as an answer. It turns out that, in general, this problem is trickier than it looks at first glance. For example, neither BufWinEnter nor BufWinLeave are triggered when a buffer is split into several windows. Will that be okay if I propose to OP to use automatic folds, or save the manual folds manually, or use mksession with ssop+=folds? I'm still unsure what he's up to. – Matt Sep 8 at 10:31
2

As others have pointed out in the question comments, this is a somewhat complex issue that I really DON'T have the expertise to expound on. That being said, the crux of the trouble I was having was related to automatic saving/loading of views (which include info on folds) when a buffer is quit/loaded.

To automatically save/load folds in vim, one adds something like the below to one's vimrc.

augroup auto_save_folds 
autocmd! 
au BufWinLeave ?* mkview
au BufWinEnter ?* silent loadview
augroup end

All the above code does is to automatically save folds when the buffer is unloaded, and automatically load the folds when the buffer is loaded. The way it does this, is via info stored in the views directory. With the above code included in the vimrc, when one looks in the ~/.vim/view (can be different in different OS'es), one sees a number of files, with filenames similar to (but interspersed with special characters throughout the name) actual files one has ever opened in vim.

Normally, the above works. But when using splits, it is a slightly different story. Each split is considered a different view, albeit of the same buffer. So when one has the same file in splits, and makes changes that affect the folds in one of the splits, then vim has no way of reconciling the changes in one split with the rest of the splits - so the information on the 'views' (folds et al) in each of the splits keeps overwriting each other. Because all of the splits use the same view to store their own info.

What needs to be done is to give the program a way to better organize this information. That's done by giving names to each of the views. Assuming a use case of 2 views, the code above would look like -

augroup auto_save_folds 
autocmd! 
au BufWinLeave ?* mkview 1
au BufWinEnter ?* silent loadview 1
au BufWinLeave ?* mkview 2
au BufWinEnter ?* silent loadview 2
.
.
augroup end

I often have up to 4-5 views, so the above numbering goes on till 5.

With this setup, when one again looks in the view directory (after opening and folding a fresh file), one can see that for each file opened in vim, there are now 2 files (), appropriately suffixed in the view directory. This way the folds in the individual splits do not overwrite each other.

So far, this has worked nicely for me, using manual folds (which I continue to stick with because of personal preferences). But, given the complex interplay of various issues here, I cannot assure that this will work for all.

  • 1
    bloody hell man, that was embarrassing! thanks for pointing it out.. – Yogesch Sep 12 at 7:53
  • 1
    Haha no worries. Regardless of your experience or lack thereof, I think this is a really nice answer. Thumbs up! – Rich Sep 12 at 8:09
  • Many thanks for the support :-) But I'm not quite sure this answer is quite accurate. Which is why I'm not going to mark it as accepted. – Yogesch Sep 12 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.