Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
JindrichPilar opened this issue Mar 4, 2019 · 12 comments
Closed

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

JindrichPilar opened this issue Mar 4, 2019 · 12 comments

Comments

@JindrichPilar
Copy link

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
Copy link
Owner

justinmk commented Mar 4, 2019

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 justinmk closed this as completed Mar 4, 2019
@JindrichPilar
Copy link
Author

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

@akarle
Copy link

akarle commented Mar 19, 2019

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
Copy link
Owner

@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
Copy link
Owner

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 justinmk reopened this Mar 19, 2019
@akarle
Copy link

akarle commented Mar 19, 2019

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
Copy link
Owner

I don't know.

@justinmk justinmk added the bug label Mar 20, 2019
@justinmk justinmk changed the title Error while running :Dirvish "pack/{}/start" package is clobbered by netrw Mar 27, 2019
@zegervdv
Copy link

zegervdv commented Oct 3, 2021

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
Copy link
Owner

justinmk commented Oct 4, 2021

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

@zegervdv
Copy link

zegervdv commented Oct 4, 2021

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 :)

@justinmk
Copy link
Owner

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
Copy link
Owner

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 #180 so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants