vim-dirvish icon indicating copy to clipboard operation
vim-dirvish copied to clipboard

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

Open JindrichPilar opened this issue 5 years ago • 11 comments

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

JindrichPilar avatar Mar 04 '19 19:03 JindrichPilar

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.

justinmk avatar Mar 04 '19 19:03 justinmk

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

JindrichPilar avatar Mar 04 '19 19:03 JindrichPilar

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

akarle avatar Mar 19 '19 00:03 akarle

@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 avatar Mar 19 '19 00:03 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.

justinmk avatar Mar 19 '19 00:03 justinmk

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?

akarle avatar Mar 19 '19 02:03 akarle

I don't know.

justinmk avatar Mar 19 '19 11:03 justinmk

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?

zegervdv avatar Oct 03 '21 09:10 zegervdv

@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..

justinmk avatar Oct 04 '21 00:10 justinmk

I am on a nightly build of Saturday, but I had the issue since switching to packer a while back (before 0.5.0) release. I only now got annoyed enough about it to look into it deeper :)

zegervdv avatar Oct 04 '21 07:10 zegervdv

I don't see this issue because I just disable netrw. However netrw is still needed for gx so I map it manually:

  use'https://github.com/justinmk/vim-dirvish.git'
  -- Disable netrw, but autoload it for `gx`.
  vim.cmd([[
    let g:loaded_netrwPlugin = 0
    nnoremap <silent> <Plug>NetrwBrowseX :call netrw#BrowseX(expand((exists("g:netrw_gx")? g:netrw_gx : '<cfile>')),netrw#CheckIfRemote())<CR>
    nmap gx <Plug>NetrwBrowseX
  ]])

justinmk avatar Jul 14 '22 00:07 justinmk

I don't see this issue because I just disable netrw.

I don't see this issue anymore even if I enable netrw.

The original issue here is a duplicate of https://github.com/justinmk/vim-dirvish/issues/180 so closing.

justinmk avatar Jun 28 '23 22:06 justinmk