All folds closed on buffer re-entry

[bitwombat]

This makes no sense, but I'm stuck.

When I switch back to a buffer (:bnext), all of my folds are folded completely. In other words, the buffer is not how I left it. If I take out vim-css-color, the problem goes away.

If I have an empty .vimrc/.vim and just install vim-css-color, there's no problem.

So, it's obviously an interaction between vim-css-color and one of my other plugins (syntastic, pathogen, ???)

Any pointers on what to look for?

[ap]

Bizarre. Doubtful that Pathogen is, err, the pathogen. Maybe you can try co-enabling just one of your other plugins at a time, and see if you can pin down the culprit that way?

[bitwombat]

After a major clean-up of my .vimrc, I'm unable to reproduce this. Closing.

[ap]

Oh well. Sorry I couldn’t help, and too bad the problem persists (whatever it was that caused it).

So it goes. :smile:

[bitwombat]

So, necro-bug. This was happening again.

My test setup is only:

pathogen in .vim/autoload vim-css-color in .vim/bundle

And only this in my .vimrc:

set foldmethod=indent
set foldlevelstart=1
let g:php_folding=1
call pathogen#infect()

I start vim *.php, it shows 1 level of folding. I open one of the folds, :bnext then :bprev and the original folding is back.

I have a feeling vim-css-color is re-loading the buffe, which is causing foldlevelstart to re-fold the buffer. The idea is supposed to be that foldlevelstart sets the fold level the first time the file is loaded into the buffer only, which would be good. This would allow me to switch from buffer to buffer and not have the folds change.

Does that make sense? Any idea of a workaround?

I've tried moving vim-css-color and :so'ing outside_bundle/vim-css-color/autoload/css_color.vim, but it doesn't seem to work.

[ap]

I have a feeling vim-css-color is re-loading the buffer

It shouldn’t, and as far as I know it doesn’t. A buffer reload does sound like one plausible explanation for the behaviour you’re seeing, but I don’t know off hand how vim-css-color could be causing that. (Maybe it still does, or maybe it triggers the behaviour in some other way, of course.)

Silly question first: have you confirmed that it doesn’t happen without vim-css-color loaded?

[bitwombat]

Silly question first: have you confirmed that it doesn’t happen without vim-css-color loaded?

Yes. With that stripped-down configuration, I can comment the pathogen#infect() call in and out, and also the foldlevelstart. It's clearly vim's foldlevelstart functionality being trigged by something vim-css-color is doing...

I'd offer to start commenting out parts of vim-css-color, but since I don't know it well I'd likely cause more code to not be engaged than I'd expect with a particular comment.

[ap]

(Hmm. Does your .vimrc include syntax on, even though you’ve not shown it here? If not, how is that getting turned on?)

[ap]

Something weird is going on here.

If I leave the after/syntax/php.vim file in place but remove the other after/syntax/ files (e.g. css.vim) (which are all getting loaded indirectly because the PHP syntax transcludes the HTML syntax, which transcludes the JS and CSS syntaxes, etc.), then the re-folding goes away and everything works fine (except the fact that not all color names get highlighted, of course – only those inside PHP strings or comments).

If I leave all the files in place but comment out the call s:parse_screen() line in css_color#enable, then the re-folding on re-entering the buffer goes away. But then non-keyword colours (i.e. hex colours like #f00) are not highlighted when re-entering a buffer, even if they had been when the buffer was previously displayed, and they only get highlighted again after the first cursor movement. So some part of the syntax highlight definitions are apparently always lost – but avoiding the s:parse_screen call somehow avoids some other part of the buffer state getting lost.

It feels like some implicit reinitialisation of some sort of buffer state happens somewhere in Vim that vim-css-color must be triggering somehow, but I don’t know what and I don’t know how, as yet.

[bitwombat]

Ick.

Glad you've reproduced it.

No, no syntax on. It isn't getting turned on; folding is by indent if that's what was confusing you. Everything's shown there.

[ap]

What’s confusing me is how vim-css-color would even be getting loaded if syntax is not enabled! 😛 Also, what purpose let g:php_folding=1 serves, if you have nothing in your vimrc to cause PHP-related plugins to load.

What does :scriptnames tell you?

I did my experiments with a syn on line in my minimal vimrc. I’d not tried to see what happens if I leave it out. Specifically, I cloned vim-css-color into ~/.vim (so that I would need no plugin manager or any kind) and put a ~/.vim/vimrc in there with these lines:

set foldmethod=indent
set foldlevelstart=1
let g:php_folding=1
syn on

With that setup I can reproduce the problem you describe. Without the syn on line, there are no folds when I launch Vim. (Also, both set ft? and set syntax? say the variables are unset, and :scriptnames lists only the vimrc and the stock plugins.) So that’s not a setup in which I can reproduce your issue.

I’ve now also tested making an empty .vim with the same vimrc and a pack/bundle/start hierarchy into which I cloned vim-css-color, using Vim 8, so that Pathogen is unnecessary but the setup is similar. Again, same results – I can reproduce with syn on but not without it.

[bitwombat]

What does :scriptnames tell you?

  1: /usr/share/vim/vimrc
  2: /usr/share/vim/vim74/debian.vim
  3: /usr/share/vim/vim74/syntax/syntax.vim
  4: /usr/share/vim/vim74/syntax/synload.vim
  5: /usr/share/vim/vim74/syntax/syncolor.vim
  6: /usr/share/vim/vim74/filetype.vim
  7: ~/.vimrc
  8: ~/.vim/autoload/pathogen.vim
  9: /usr/share/vim/vim74/ftoff.vim
 10: /usr/share/vim/vim74/plugin/getscriptPlugin.vim
 11: /usr/share/vim/vim74/plugin/gzip.vim
 12: /usr/share/vim/vim74/plugin/logiPat.vim
 13: /usr/share/vim/vim74/plugin/matchparen.vim
 14: /usr/share/vim/vim74/plugin/netrwPlugin.vim
 15: /usr/share/vim/vim74/plugin/rrhelper.vim
 16: /usr/share/vim/vim74/plugin/spellfile.vim
 17: /usr/share/vim/vim74/plugin/tarPlugin.vim
 18: /usr/share/vim/vim74/plugin/tohtml.vim
 19: /usr/share/vim/vim74/plugin/vimballPlugin.vim
 20: /usr/share/vim/vim74/plugin/zipPlugin.vim
 21: /usr/share/vim/vim74/syntax/php.vim
 22: /usr/share/vim/vim74/syntax/html.vim
 23: /usr/share/vim/vim74/syntax/javascript.vim
 24: ~/.vim/bundle/vim-css-color/after/syntax/javascript.vim
 25: ~/.vim/bundle/vim-css-color/autoload/css_color.vim
 26: ~/.vim/bundle/vim-css-color/syntax/colornames/extended.vim
 27: ~/.vim/bundle/vim-css-color/syntax/colornames/basic.vim
 28: /usr/share/vim/vim74/syntax/vb.vim
 29: /usr/share/vim/vim74/syntax/css.vim
 30: ~/.vim/bundle/vim-css-color/after/syntax/css.vim
 31: ~/.vim/bundle/vim-css-color/after/syntax/html.vim
 32: /usr/share/vim/vim74/syntax/sql.vim
 33: /usr/share/vim/vim74/syntax/sqloracle.vim
 34: ~/.vim/bundle/vim-css-color/after/syntax/php.vim

Grepping them all,

/usr/share/vim/vimrc: syntax on

That file comes from vim-common on my Ubuntu 16.04 system, and its version is Version: 2:7.4.1689-3ubuntu1

[ap]

Well then, one mystery down. Progress!