Don't block when doing from import expansion about deoplete-jedi HOT 13 CLOSED

Deoplete only delays completions, it never blocks input. If you have jedi-vim installed, you will need: let g:jedi#completions_enabled = 0

from deoplete-jedi.

@tweekmonster Yes, I have jedi-vim installed and yes I already have let g:jedi#completions_enabled = 0

from deoplete-jedi.

@tweekmonster Okay, I can't reproduce this behavior. I'll reopen the issue if this would happen again.

from deoplete-jedi.

@purpleP You can try clearing the cache in ~/.cache/deoplete/jedi to see if the issue happens again.

from deoplete-jedi.

@tweekmonster Yeah, as I've said it only happens when there's no cache (more precisely I think when I open project for the first time). So I've already found ~/.cache/deoplete and ~/.cache/jedi and have been removing them on each try. It really looks like there is some hidden cache somewhere. Like maybe jedi process runs somewhere independently and stores it in memory or something.

from deoplete-jedi.

Sounds like jedi-vim's g:jedi#smart_auto_mappings https://github.com/davidhalter/jedi-vim/blob/ef05bc402a5698ec3a33f8cfde645a38ccc1211c/ftplugin/python/jedi.vim#L40-L42.
It is not affected by the g:jedi#completions_enabled = 0 switch AFAIK?! - but maybe should be?!

from deoplete-jedi.

Sounds like jedi-vim's https://github.com/davidhalter/jedi-vim/blob/ef05bc402a5698ec3a33f8cfde645a38ccc1211c/ftplugin/python/jedi.vim#L40-L42.
It is not affected by the g:jedi#completions_enabled = 0 switch AFAIK?! - but maybe should be?!

I was just looking into this before you posted, but I got confused because I'm using the default settings. It turns out my insert <space> map is used by the auto-pairs plugin so I wasn't affected.

It looks like this is the culprit.

Replying to @purpleP in case let g:jedi#smart_auto_mappings = 0 doesn't work:

Like maybe jedi process runs somewhere independently and stores it in memory or something.

The only cache that exists for deoplete-jedi is in ~/.cache/deoplete/jedi and it's a cache that's incompatible with Jedi's. deoplete-jedi disables Jedi's cache entirely and the completion server isn't forked, so it won't survive if the parent process dies. I don't think the Jedi module factors into this. You're restarting nvim after clearing the disk cache, right?

It's technically impossible for deoplete-jedi to block keyboard input in the nvim process. The only way for it to block would be to call out to a Vim function from Python and deoplete-jedi doesn't do that.

from deoplete-jedi.

@blueyed @tweekmonster Okay, because of my previous fiddling with jedi-vim I know what was the problem. I've defined jedi setttings like g:jedi#completions_enabled in my after/python.vim and I don't know why, but neovim (and vim probably too) loads jedi first and my settings later. I moved settings to vimrc and everything works smoothly now. Why is vim doing this?

from deoplete-jedi.

@purpleP
I think after/python.vim should be after/ftplugin/python.vim, or after/plugin/my-python.vim to have a global plugin. Try adding echoerr "foo" in there (after/python.vim), it is probably never sourced?!

from deoplete-jedi.

@blueyed Yes, sorry, I meant after/ftplugin/python.vim. It is sourced.

from deoplete-jedi.

@purpleP
It it probably to late there, since jedi-vim the setup already?!

from deoplete-jedi.

@blueyed well, obviously, but why Jedi sourced before my settings?

from deoplete-jedi.

ftplugin is handled when the filetype is handled (on-demand).
And even with after/plugin/ you are doing your stuff explicitly _after_wards.. ;)

from deoplete-jedi.