On first edit, default foldmethod is lost.
Parakleta opened this issue · 14 comments
When I edit a file for the first time (i.e. no view information is available) FastFold is not preserving the global (default) foldmethod.
The sequence that goes wrong seems to be that somehow Enter is running twice, and on the first run it stores the default foldmethod (syntax in my case) correctly in w:lastfdm and sets the local foldmethod to manual, but then on the second run because the local foldmethod is now manual it is deciding that the file is no longer 'reasonable' and so unlets the w:lastfdm value which was holding the default of syntax.
This autocommand stuff hurts my head so I have no suggestion for what might fix this issue.
First off, are you using the latest version ? There is a new check if exists('g:SessionLoad') | return | endif to prevent the second SessionLoadPost autocmd to trigger prematurely.
If that's not the problem, I guess you are using vim-stay? Could you try with restore_view.vim (that does not change the foldmethod) loaded BEFORE FastFold, and check if the issue persists?
@kopischke The problem is that vim-stay issues a SessionLoadPost autocmd at https://github.com/kopischke/vim-stay/blob/986f7b5c22b2601093d2162ac03dfcae223a10fb/autoload/stay/view.vim#L46 where FastFold does not expect it, namely when there was no view info loaded. That causes s:Enter() to be called twice, on the second time with fdm=manual.
I guess I'll add an additional check for fmd=manual
Ok, the latest commit should resolve it.
the problem is that vim-stay issues a SessionLoadPost autocmd where FastFold does not expect it, namely when there was no view info loaded. That causes
s:Enter()to be called twice, on the second time withfdm=manual.
@Konfekt do I understand correctly that the problem would go away if SessionLoadPost was only fired by vim-stay when an actual view session file has been loaded?
Yep, with FastFold as of commit 324ba28 it would have gone away.
But with the latest commit resolved this issue by better means; so everything can stay as is and all the noise was in vain.
As an aside it is however curious that SessionLoadPost triggers even if vim-stay does not load a view file; is this on purpose?
As an aside it is however curious that
SessionLoadPosttriggers even if vim-stay does not load a view file; is this on purpose?
Nope, pure sloppiness when implementing that feature. I’ll correct that no matter what.
Perhaps you can leave it out? (There's a doautocmdall SessionLoadPost in every view file).
It turns out there is no straightforward way to check if a view session file was actually found: loadview returns silently if there is no session file, v:this_session is only set for “real” sessions, and faffing around with parsing the output of 2verbose loadview in combination with redir is a bag of hurt… damn.
That leaves us with the unsatisfactory situation that, as the doautoall included in view session files triggers a costly re-evaluation of modelines in all buffers, which causes the delay I have documented, it is unacceptable to not suppress autocommands when loading views in vim-stay, but that triggering spurious SessionLoadPost events has unintended side effects, as we have just seen.
@Konfekt any ideas? I’m all out…
Belay that: SourcePre registers a view session load. Might be the thing I need.
Ah, SourcePre should be it!
I'm not sure if artificially triggering SessionLoadPost has side effects for carefully crafted plugins, and FastFold handles it fine now too.
By the way, perhaps you can surpress the autocmds only if the g:SessionLoad variable is set, this way you check if a session is being loaded and thus a lot of autocmd's triggered almost simultaneously, stumbling over each other.
@Konfekt fixed on vim-stay’s side as of release 1.3.0. SessionLoadPost now should only be fired if a view session file was found and there is an autocommand defined for it.
Thanks! This was a very utile bug report by @Parakleta as it pointed out shortcomings in either plugin of ours.