Closed bew closed 6 years ago
Your solution looks good to me at a first glance. I'll take a close look asap.
I merged the two commits on your branch into my repo and did some code shuffling afterwards. Thanks for the report and the changes!
You're welcome, I can't test right now, but if you took my commits it should be good, we can close this issue?
I think everything works as expected. I reproduced the error and did check the correct behavior after my changes. If something is still not working we just reopen this issue. Closing for now.
Repro steps:
I modified the plugin to add more debug bew/vim-localvimrc@da04133.
Minimal
bug.vimrc
(using vim-plug):Minimal
.lvimrc
:Notice that I call the
s:LocalVimRCDebug
from the executed script, the script number is 12 for me on vim (it is 9 on neovim), but it might differ for you.Open vim using:
vim -u bug.vimrc file1 file2
Now run::LocalVimRCEnable
It'll ask twice to load the
.lvimrc
file and accept the non-sandbox run. (not sure if it's intended) Edit: With the fix I describe at the end, it asks only once, so I guess it was not intended.Then you'll see the errors:
The debug logs (from
:LocalVimRCDebugShow
):(I added some spaces for reading convenience)
You can see that there is 2 invocation of
LocalVimRC()
! This is visible in the logs: the second invocation is afterfrom .lvimrc: before `bufdo write`
and before the lastfrom .lvimrc: after `bufdo write`
.What happens is that
bufdo write
will trigger theBufWinEnter
event which will trigger the 2ndLocalVimRC()
. I wonder why it only recurse once, maybe it is a security in autocmdSolution?
I think a possible solution would be to add a guard around the
.lvimrc
script execution and at the beginning ofLocalVimRC()
to make sure it's not called (or it returned at the guard) during a.lvimrc
execution.WDYT?
Edit: With the mentionned fix it works perfectly, checkout my branch bew/vim-localvimrc@fix-recursive-call. I can make a PR if you think it's a good way to fix this
Also, the debug logs are much cleaner: