Closed da-x closed 6 years ago
Hi. First, thank you for the bug report and the time you took investigating the issue!
After further investigations on my side, I'm under the impression that an old design choice is the root of the problem you've observed. I'd rather start by fixing it: SourceLocalPath()
should receive an absolute pathname and not a dirname. Would you mind rebasing your patch to just change that, and also tell me whether it fixes you issue?
i.e.:
@@ -122,7 +122,7 @@ set cpo&vim
" Avoid global reinclusion }}}1
"------------------------------------------------------------------------
" Commands {{{1
-command! -nargs=0 SourceLocalVimrc call s:SourceLocalVimrc(expand('%:p:h'))
+command! -nargs=0 SourceLocalVimrc call s:SourceLocalVimrc(expand('%:p'))
" Default Options {{{1
function! s:get_permission_lists()
@@ -215,7 +215,7 @@ aug LocalVimrc
" As some plugins use global option, we need to load local vimrcs on
" BufEnter, even if they've been already loaded on BufEnter and BufNewFile.
" TODO: Register that BufLeave hasn't been triggered => no need to reload
- au BufEnter,BufRead,BufNewFile * :call s:SourceLocalVimrc(expand('<afile>:p:h'))
+ au BufEnter,BufRead,BufNewFile * :call s:SourceLocalVimrc(expand('<afile>:p'))
" => Update script version every time it is saved.
for s:_pat in s:local_vimrc
exe 'au BufWritePre '.s:_pat. ' call lh#local_vimrc#_increment_version_on_save()'
Note that even if %
and <afile>
are interchangeable in the context of the events I'm currently listening, I'd rather avoid using %
to make any choice. The buffer-id (if it's really needed) should be bufnr(a:path)
.
After that, I'll have other patches in order to instrument what triggers the function, and to avoid sourcing a local vimrc several times when the current buffer hasn't changed.
Thanks, the patch that you propose seems to fix the issue.
I took the opportunity to finally define a CONTRIBUTORS
file. Along the way, I've seen that :SourceLocalVimrc
using a directory name has been introduced in PR #5.
@szeist, do you remember in which scenario you observed your issue with path heads? And could you tell me whether the new patch I propose for this PR #12 introduce a regression in your use case?
Issue fixed in master.
Thanks.
The problem I've seen is the following:
Execute vim on a file, e.g.
vim <some-c-file>
, local_vimrc works perfectly. Then, open another file of the same time in the same directory using NERDTree - boom. It does not load the relevant local_vimrc file.I turned on verbosity and saw that the file is 'forbidden' because the containing directory pathname was provided to
lh#project#is_eligible()
which in turn used it onbufname()
, which returns an empty string because it matched the directory on more than one buffer.The underlying function
lh#project#is_eligible()
works better with buffer IDs and not paths, I think that is what should be given to it.