Closed ocehugo closed 4 years ago
It is the problem of jedi. It should be reported in jedi issues.
The only caveat here is that I couldn't find a simple source code to trigger it. I can easily reproduce in a piece of code that I have but that depends on custom installed packages.
And your report is not reproducible. Please create the sample code. If not, your report will be ignored unfortunately.
You can try the latest jedi by https://github.com/deoplete-plugins/deoplete-jedi/pull/250.
Thanks for the quick reply, and I understand if this is closed.
However, my expectation with the case above was that deoplete/deoplete-jedi could handle those errors in a more polite way instead of getting in the way :). For example, the stack msg could go into :messages instead of interrupting my typing.
Your report is not reproducible. So I cannot improve the error handling.
And you can disable errors by options. https://github.com/deoplete-plugins/deoplete-jedi/blob/master/README.md#options
FYI:
1.let g:deoplete#sources#jedi#ignore_errors = 1
still trigger the error msg/interruption.
I tried #250 & still happening.
I dig further and the problem appears to be in jedi goto method of HelperValueMixin - there is no RecurssionError handling when inspecting names. I tried to dig up where the blamed recursion is happening but didn't have enough time to find a way to trigger the problem and have a proper pdb at to inspect (and the lack of code docstrings did not help much).
Will send something to jedi repo - thanks
OK. I will fix ignore_errors_problem.
@ocehugo Please test https://github.com/deoplete-plugins/deoplete-jedi/pull/252.
@ocehugo Ping.
@Shougo - #252 still didn't catch it. FYI: upstream issue is here https://github.com/davidhalter/jedi/issues/1515
Really?? I have tested and it catched errors. Please upload reproducible instruction.
And stacktrace again. I don't work non reproducible problems
I was surprised too. I'll try again soon when I got the opportunity. maybe I opened a old session or some cache issue.
You are Pythonista. So you can debug it effectively
Please test the latest version.
Problem summary
I'm getting a very long stack trace from deoplete related to jedi completion of docstrings.
The problem appears when using the docstring completion of jedi and editing variable names or function arguments that already exists. It takes me 15s to go through the entire stack in vim because it's deeply recursive. It's also easy to keep holding j, triggering the problem again because of a new insert, and then causing deoplete to be disable given too many errors.
The only caveat here is that I couldn't find a simple source code to trigger it. I can easily reproduce in a piece of code that I have but that depends on custom installed packages.
Expected
deoplete can handle the docstring completion or just say "error in looking for docstring in [method,func,...]".
Environment Information
Provide a minimal init.vim with less than 50 lines (required)
Steps to reproduce the issue after starting Neovim (required)
Upload the logfile(s)
deoplete log : http://dpaste.com/36MGD6G python logs: all-empty Non-repeated bit of the stack trace: http://dpaste.com/1TSJH8T