"pack/{}/start" package is clobbered by netrw

[JindrichPilar]

I have been cleaning up my Neovim config and setting up vim-plug to load plugins only when needed.
I get the same error by just running :Dirvish.

I tried this configuration:

Plug 'justinmk/vim-dirvish', { 'on': '<Plug>(dirvish_up)'}
if mapcheck('-', 'n') ==# '' && !hasmapto('<Plug>(dirvish_up)', 'n')
  nmap - <Plug>(dirvish_up)
endif

But when I invoke - I get an error and plain netrw opens.

Error detected while processing function dirvish#open[39]..<SNR>39_open_dir[43]..<SNR>39_buf_render:
line   16:
E21: Cannot make changes, 'modifiable' is off:   silent keepmarks keepjumps %delete _

Software:

• Archlinux
• NVIM v0.3.4

[justinmk]

Remove { 'on': '<Plug>(dirvish_up)'} . There's zero reason to lazy-load dirvish via your plugin manager: Dirvish already has its code in autoload/, which does lazy-loading via Vim's own mechanisms.

Spending time figuring out how to support lazy-load workarounds in plugin managers makes no sense. The only reason plugin managers have that feature is to work around plugins that are not properly autloaded.

[JindrichPilar]

Thank you for your really swift answer. I didn't realize lazy-load was already supported.

[akarle]

Hi @justinmk ,

I'm getting the same error on my end. Neovim 0.3.4, no package manager (just packages feature)

I was able to reproduce it consistently. It seems to be tied to netrw. More specifically, when I execute vim as so:

nvim .

It opens nvim in netrw NOT dirvish. Then, the output of :nnoremap - shows both plugins:

n  -           *@:<C-U>call <SNR>40_NetrwBrowseUpDir(1)<CR>
n  -             <Plug>(dirvish_up)

If I navigate to a file in that directory, open it, and hit -, I get the above error.

Couple (hopefully) quick questions:

1. I was under the impression there was only one mapping per key--is this wrong?
2. Is there any workaround you see to this? It only occurs when I start neovim with the opening buffer being a directory.

Thanks for any help you can give, and for the great plugin!

Alex

[justinmk]

@akarle

1. the * means buffer-local mapping
2. depends on how you're using the packages feature. Sounds like you are calling :packload at the wrong place.

[justinmk]

Seems like doing :packloadall fixes this issue. Which implies that there's an ordering thing that needs to be figured out in light of vim8 packages feature.

[akarle]

Thanks for the fast response! Good to know about the buffer local mappings.

So if I understand correctly, this can currently be fixed by:

1. :packloadall in a vimrc, which forces Vim to source all the pack/{}/start directories before the vimrc is finished loading (and thus before netrw is loaded)
2. sourceing the plugin/dirvish.vim explicitly in the vimrc/init.vim to force dirvish to take precedence
3. Disable netrw:

" somewhere in .vimrc / init.vim
let g:loaded_netrwPlugin = 1

@justinmk To clarify (and for my own curiosity) -- do you suspect this issue to be an ordering thing that would be fixed in this plugin? or that would be fixed on the (Neo)Vim side of things?

[justinmk]

I don't know.

[zegervdv]

Sorry to dig up an old issue, but I am seeing the same since moving to packer.nvim (which uses packages).

:scriptnames suggests that dirvish is loaded after the netrwPlugin.

...
 39: /home/linuxbrew/.linuxbrew/Cellar/neovim/HEAD-23d13aa/share/nvim/runtime/plugin/netrwPlugin.vim
...
 70: ~/.local/share/nvim/site/pack/packer/start/vim-dirvish/plugin/dirvish.vim
...
 88: ~/.local/share/nvim/site/pack/packer/start/vim-dirvish/autoload/dirvish.vim
 89: ~/.local/share/nvim/site/pack/packer/start/vim-dirvish/ftplugin/dirvish.vim
 90: ~/.local/share/nvim/site/pack/packer/start/vim-dirvish/syntax/dirvish.vim
 91: /home/linuxbrew/.linuxbrew/Cellar/neovim/HEAD-23d13aa/share/nvim/runtime/autoload/netrw.vim
 92: ~/.local/share/nvim/.netrwhist

If I mark dirvish as optional and packadd vim-dirvish in my config, it is loaded before the netrwPlugin and the directory is opened by dirvish.
So it seems vim packages are always loaded after the builtin packages. Other package managers probably run from your init.vim and therefore load before the built-in ones?

[justinmk]

@zegervdv what nvim version? Latest nvim master has changed behavior of package loading. Not sure if it affects anything here but good to know for reference..