Closed lucc closed 8 years ago
Thank for noticing this! I'm not sure that suppressing their plugin is the best idea, because it could be modified eventually, regressing our bug. I wonder where did neovim get their plugin in first place? Perhaps, we could have it substituted with this one as more versatile?
According to the git log of neovim they (man.vim
in plugin
, ftplugin
, syntax
...) seem to come from vim. The move from ftplugin
to plugin
happened in neovim. ftplugin/man.vim
seems to exist in the vim repository since 2004.
All right, neovim just activated the stable plugin. So I agree with your suggestion then. UPD: However, your fix wouldn't work for me since the stock plugin is loaded before this one (hence my original problem #33).
2015-12-19 2:52 GMT+02:00 Lucas Hoffmann notifications@github.com:
According to the git log of neovim they (man.vim in plugin, ftplugin, syntax ...) seem to come from vim. The move from ftplugin to plugin happened in neovim. ftplugin/man.vim seems to exist in the vim repository since 2004.
— Reply to this email directly or view it on GitHub https://github.com/vim-utils/vim-man/pull/35#issuecomment-165928776.
@sakhnik did you really try this?
I think if this plugin is loaded after the default one we will just overwrite the command defined in the standard plugin. The guard is only needed (and useful) if for some reason the standard plugin is loaded after this plugin.
I haven't noticed any problems with :Man
recently. And :verbose command Man
points to this plugin. Hence, the code in master is functional for me.
You are right
The
man.vim
file that is shipped with nvim is shadowing:Man
. This turns of completions for the command. Is this also the case for you? (Try:verbose command Man
to see where the command was defined.)This PR will bring back the
g:loaded_man
variable to stop the buildinman.vim
from being sourced. This fixes the issue for me.cc @sakhnik, #33, #34