I am using the example configuration linked in the readme: https://gist.github.com/afnanenayet/8c2ee0fdabb8d1e292b788f9723673c5
It appears this was removed, but cannot find the replacement: https://github.com/Shougo/deoplete.nvim/blob/master/doc/deoplete.txt#L1664
When I open nvim, I get this error:
Unknown function: deoplete#custom#source.
For the configuration to work.
deoplete version(SHA1):
165e693cbb1198569954b2a01f7ba56026bf7ddf
OS:
macOS
:version output:NVIM v0.2.2
:checkhealth or :CheckHealth result(neovim only):g:python3_host_prog is not set. Searching for python3 in the environment.gem environment.https://gist.github.com/afnanenayet/8c2ee0fdabb8d1e292b788f9723673c5
Your configuration is invalid.
Because it does not work.
Provide a minimal init.vim/vimrc with less than 50 lines (Required!)
You have not read the sentense. The init.vim must be executable like this.
$ nvim -u your_minimal_init.vim
I will close the issue.
Hint:
I think you does not load deoplete.nvim.
You need to set runtimepath before calling call deoplete#custom#source().
You should learn about Vim script.
" Your minimal init.vim/vimrc
set runtimepath+=~/path/to/deoplete.nvim/
let g:deoplete#enable_at_startup = 1
Stumbled over this problem too, and I figured I might give a slightly better answer than the current one.
As already mentioned, this isn't a deoplete issue - it's a config issue. It's not specific to this plugin either; it can be triggered by different plugins, and it depends on your .vimrc.
I personally found it extremely weird, because I only got that error on boot. All my testing used source ~/.vimrc, but any hard reset triggered the error. Sourcing after the error actually fixed any issues caused my the statements not being called. I had the problem with another plugin as well (functions not found in spite of them existing, verified at runtime with sourcing as well as copy-pasting the line into a :call statement.
This is more of an issue with how these scripts manage the runtime path. It's described here - some (if not all, I'm honestly not sure) plugin managers don't add it instantly after the load command. The end command modifies the runtime path.
So yeah, the plugin isn't loaded yet.
There's basically two options. As I mentioned, the plugins aren't necessarily loaded after the actual line that defines the plugin use - it's loaded later.
The first option, as outlined in the answer, autocmd:
autocmd VimEnter * call deoplete#custom#source('_', 'disabled_syntaxes', ['Comment', 'String'])
Once it enters, it should be loaded by most plugin managers.
Alternatively, move the config after the end statement for whatever plugin manager you use:
...
Plug 'Shougo/deoplete.nvim'
call plug#end() " Or some other function
call deoplete#custom#source('_', 'disabled_syntaxes', ['Comment', 'String'])
I only tested this with Plug, but I imagine it should apply to the rest as well. Removed the errors for me anyway (LanguageServer integration).
TL;DR: use autocmd to delay the execution, or call it after the runtime path is set (with a plugin manager: after the end call)
You must call deoplete#custom#source() after plug#end().
Because, plug#end() add plugins runtimepath.
It is vim-plug's feature.
Most helpful comment
Stumbled over this problem too, and I figured I might give a slightly better answer than the current one.
As already mentioned, this isn't a deoplete issue - it's a config issue. It's not specific to this plugin either; it can be triggered by different plugins, and it depends on your .vimrc.
I personally found it extremely weird, because I only got that error on boot. All my testing used
source ~/.vimrc, but any hard reset triggered the error. Sourcing after the error actually fixed any issues caused my the statements not being called. I had the problem with another plugin as well (functions not found in spite of them existing, verified at runtime with sourcing as well as copy-pasting the line into a:callstatement.This is more of an issue with how these scripts manage the runtime path. It's described here - some (if not all, I'm honestly not sure) plugin managers don't add it instantly after the load command. The end command modifies the runtime path.
So yeah, the plugin isn't loaded yet.
There's basically two options. As I mentioned, the plugins aren't necessarily loaded after the actual line that defines the plugin use - it's loaded later.
The first option, as outlined in the answer, autocmd:
Once it enters, it should be loaded by most plugin managers.
Alternatively, move the config after the end statement for whatever plugin manager you use:
I only tested this with Plug, but I imagine it should apply to the rest as well. Removed the errors for me anyway (LanguageServer integration).
TL;DR: use autocmd to delay the execution, or call it after the runtime path is set (with a plugin manager: after the end call)