Dictionary required error

[wuzzapcom]

Installed your plugin and got this error:

Error detected while processing function esearch#init[1]..<SNR>14_init_lazy_global_config:
line    2:
E715: Dictionary required  

I am sorry, if I have`t figured something out.

[eugen0329]

Can you provide an output of :echo g:esearch, please?

It seems like you've setup g:esearch variable incorrectly. The solution is to use dict (let g:esearch = {}) or remove it at all if you prefer to use the defaults.

[wuzzapcom]

I will attach this output in a few hours. I haven’t set any stuff in my vimrc(plugin installed via Pathogen) My OS: macOS High Sierra.

[eugen0329]

Does it happen before the first run or after?

[wuzzapcom]

Hmm, I've got interesting situation.
I am newbie in vim world, so I can do something wrong.
When I entered :echo g:esearch into vim command line, I got this:
E121: Undefined variable: g:esearch E15: Invalid expression: g:esearch
When I tried today to reproduce described error, I've got this:
Error detected while processing function esearch#init[1].. <SNR>15_init_lazy_global_config[3]..esearch#opts#new: line 28: E484: Can't open file /var/folders/gn/_5kr0_7x1sjfxzhlsyn0dpgm0000gn/T/vUHwCvm/1
And this happens before first run. In other words, I have no any successful result with this plugin.

[eugen0329]

Hmm, that's really weird. Please, try to update the plugin (should be smth like cd ~/.vim/bundle/vim-esearch && git pull origin master in your shell) and provide me a version of your vim (in open vim editor just paste :version and append the result). My output of :version is:

:version
NVIM v0.2.0
Build type: RelWithDebInfo
Compilation: /usr/bin/x86_64-linux-gnu-gcc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DDISABLE_LOG -Wdate-time -D_FORTIFY_SOURCE=2
 -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -DDISABLE_LOG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnost
ics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/build/neovim-LpFVCC/neovim-0.2.0/build/config -I/build/neovim-LpFVCC/neovim-0.2.0/src -I/usr/include -I/usr/include -I/usr/inc
lude -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/build/neovim-LpFVCC/neovim-0.2.0/build/src/nvim/auto -I/build/neovim-LpFVCC/neovim-0.2.0/build/include
Compiled by pkg-vim-maintainers@lists.alioth.debian.org

Optional features included (+) or not (-): +acl   +iconv    +jemalloc +tui
For differences from Vim, see :help vim-differences

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

After that the options are the following:

1. run :echo system('git rev-parse --is-inside-work-tree &>/dev/null') and provide an output here. In a happy case the output should be blank. Exactly the last error my occur due to some kind of a wrong escaping.

2. Try to use explicit configuration:

   let g:esearch = {
   \ 'adapter':    'grep',
   \ 'backend':    'system',
   \}

   This config doesn't provide async features though and also it doesn't require additional utils installed, so it should work in any version. BTW later I would suggest to use vim8 or neovim to enable async updates and more rapid search util like the_silver_searcher that is much faster than builtin grep.

[wuzzapcom]

Situation becomes really strange.
Here is my version:

By the way, I checked plugin in terminal vim, it does not works too.
Result of :echo system('git rev-parse --is-inside-work-tree &>/dev/null') E484: Can't open file /var/folders/gn/_5kr0_7x1sjfxzhlsyn0dpgm0000gn/T/vBZX6Vv/1 I checked this path, there is no file named 1, this folder is empty. Tried explicit configuration, it's failure again.
Error detected while processing function esearch#init[1]..<SNR>15_init_lazy_global_config[9]..esearch#opts#new: line 28: E484: Can't open file /var/folders/gn/_5kr0_7x1sjfxzhlsyn0dpgm0000gn/T/vwtFrZb/1 Honestly, it is looks like not plugin problem, but vim's. What if vim just don't have possibility write to this folders?

[wuzzapcom]

OMG, I figured this out. It was really about impossibility of vim to read temp files. I use fish and it is same problem. Mind-blowing problem. Thank you for your help :)

[eugen0329]

You are welcome than! Please, feel free to reopen if the issue still occurs. Although still cannot imagine why fish could impact on permissions that actually belong to the fs level :thinking:.

[wuzzapcom]

Agreed, this is really strange thing. I will open issue in their repo :) Will write you, if they tell me something worthwhile.

[eugen0329]

great, thanks :)

[wuzzapcom]

That is it :)

[eugen0329]

Thanks! Actually no chance to check it right now on osx, but I believe that merging out streams separately from redirecting to /dev/null should help (at least according to stack overflow answers).