FastFold don't set manual foldmethod after open with `:e`

[lervag]

Given the following vimrc file (see below) and the following steps:

1. Open vim with vim -u minivimrc (or gvim)
2. Open a wiki file with :e test.wiki
3. Try to insert text with i

An update from neocomplete now outputs an error when the foldmethod is expr. Since I use FastFold, I thought it should automatically change the foldmethod to manual, but in this case, it remains expr. I think the problem is due to a lacking autocommand, but I haven't studied this in detail.

set nocompatible

let &rtp = '~/.vim/bundle/neocomplete/,' . &rtp
let &rtp = '~/.vim/bundle/vimwiki/,' . &rtp
let &rtp = '~/.vim/bundle/FastFold/,' . &rtp

filetype plugin indent on
syntax enable

if has('gui_running')
  set lines=56
  set guioptions=aeci
else
  set t_Co=256
endif

let g:vimwiki_folding = 'expr'

let g:neocomplete#enable_at_startup = 1
let g:neocomplete#sources#omni#input_patterns = {}
let g:neocomplete#force_omni_input_patterns = {}
let g:neocomplete#sources#omni#input_patterns.vimwiki = '\[\[\S*'
let g:neocomplete#force_omni_input_patterns.vimwiki = '\[\[[^]|]*#\S*'

[Konfekt]

Ok. I think vimwiki at

https://github.com/vimwiki/vimwiki/blob/3bd3d9b86036b21aecd69f0a1e572643d626c280/plugin/vimwiki.vim#L438

only sets up the filetype settings, such as folding, at the BufWinEnter event, and not at the FileType event that FastFold expects. Let's see what we can do.

[Konfekt]

Ok, reproducible. See, at

https://github.com/vimwiki/vimwiki/blob/3bd3d9b86036b21aecd69f0a1e572643d626c280/plugin/vimwiki.vim#L159

the foldmethod is only set AFTER the filetype when the FastFold autocmd fires. Somehow, when setting the foldmethod in a FileType autocmd or in a ftplugin/*.vim file, it is detected by the FastFold FileType autocmd. Perhaps vimwiki should revert the order but maybe there's an elegant solution to this in FastFold too.

[Konfekt]

Well, with latest Vim, the OptionSet autocmd now should take care of it. Can you check? Maybe it does not, because the BufWinEnter autocmd is not nested. Really, the foldoptions should go into a ftplugin/*.vim in vimwiki.

[lervag]

I'm on Arch Linux that was updated today. Vim version 7.4.1529. The OptionSet autocommand exists. The problem persists.

Perhaps this is a vimwiki issue (at least sort of). I don't understand why the foldmethod is not set in the ftplugin file. The comment says:

Settings foldmethod, foldexpr and foldtext are local to window. Thus in a new tab with the same buffer folding is reset to vim defaults. So we insist vimwiki folding here.

I think the following code is bad in any case, because it sets the foldmethod and does normal zE when no option is specified.

Anyway, I would be happy if we could find a solution from the FastFold point of view. vimwiki is good, but the maintenance is not very good. The development is slow and as you see, there are alot of open issues.

[Konfekt]

The obvious remedy would be to add a BufWinEnter autocmd. However, for every filetype other than vimwiki that would just double the FileType autocmd since every other plugin and Vim itself sets all options in FileType autocmd, and (after/)ftplugin/... before firing the FileType autocmd . That makes vimwiki's code special.

How about as a workaround adding a autocmd FileType vimwiki set fdm=expr to your .vimrc ?

[lervag]

It does not help to use an autocommand with setl fdm=expr; FastFold still does not detect and disable the foldmethod.

Are you sure a BufWinEnter autocmd from FastFold is harmful?

For the moment, I'm solving it with

augroup MyVimwiki
  autocmd!
  autocmd BufWinEnter *.wiki FastFoldUpdate
augroup END

I think perhaps the problem should be resolved from the vimwiki side, not from the FastFold side. If vimwiki allowed to not interfere with the fold settings at all, then one could simply set the foldmethod manually in the regular way.

[Konfekt]

The foldmethod in vimwiki best goes into a FileType autocmd or ftplugin/*.vim.

But I added the BufWinEnter autocmd. The rationale is that it must be there anyway, to account for modelines. By a quick check, does not seem to affect opening files that much.

Does it work now?

[lervag]

Thanks, it works as expected now.