BufEnter should trigger ProjectionistDetect

[AntonyBlakey]

I am on Neovim 0.3.1 on Ubuntu.

When I use gf to go to a file, and then Ctrl-O to come back, the path seems reset i.e. doesn't include the "path" key entries from my .projections.json file. The other settings ("start" & "make") are unaffected by the gf/Ctrl-O dance. I found that adding the following in my init.vim fixes the problem. I am a relative newbie to vim, so I'm not sure if this is the best fix.

  augroup projectionist-fix
    autocmd!
    autocmd BufEnter *
          \ if (&filetype ==# 'netrw' && !exists('b:projectionist')) ||
          \     &buftype !~# 'nofile\|quickfix' |
          \   call ProjectionistDetect(expand('%:p')) |
  augroup END

[tpope]

Check :verbose set path? to see what might be clobbering it. BufEnter fires on all sorts of things so it's a crude hammer to swing at this problem.

[AntonyBlakey]

It's vim-apathy :( Doesn't play well with vim-projectionist's "path" key.

[tpope]

What filetype? Apathy mostly appends and prepends so it's (probably) not the root cause.

[AntonyBlakey]

C/C++.

I removed my 'fix', and on a hunch removed vim-apathy. Suddenly everything was cool. So it might be a more complicated chain of interactions, but that's a pretty simple datapoint.

I haven't done the :verbose debug technique because I've now started working on a solution using compile_commands.json to update the .projections.json path key. I have a cross-platform build chain, so in any case I need the dynamic determination of platform-dependent builtin paths.

[tpope]

Are you sure it's not just sorted differently than you expect?

[AntonyBlakey]

No - when I come back from gf + C-o the path addition from projectionist is gone on my c file (it's reset to the apathy-computed value) , and no subsequent gf in that file works.

But yes apathy + projectionist does initially break the projectionist comment about the path addition being prepended to the path, which was only a minor concern.

[tpope]

Confirming I can't reproduce with C. Both plugins prepend so order may be unpredictable, but I don't see any mechanism for it to clobber.

Maybe it's not running at all. Before navigating, do a :unlet b:start, and see if it gets set upon return.