* jedi_vim.jedi_import_error: add location
This is useful for debugging. It contains e.g. the path to parso, if
importing failed from there.
Example:
> Error: jedi-vim failed to initialize Python: jedi#setup_python_imports: could not import jedi: cannot import name 'PythonTokenTypes' (in /…/jedi-vim/pythonx/jedi/jedi/api/completion.py:1). (in function jedi#init_python[3]..<SNR>44_init_python[27]..jedi#setup_python_imports, line 37)
* init: handle jedi_vim.jedi_import_error in Vim plugin
Using `set shortmess+=F` would suppress the `:echom` used in
`jedi_vim.no_jedi_warning` [1].
This patch makes `jedi#setup_python_imports` handle the error instead.
1: https://github.com/neovim/neovim/issues/8675
* Revisit error handling with loading jedi_vim
* jedi#debug_info: display parso submodule separately
* Fix jedi#reinit_python
* fixup! Revisit error handling with loading jedi_vim
* display_debug_info: handle exceptions with environment.get_sys_path
* fixup! Revisit error handling with loading jedi_vim
[ci skip]
- cache current environment
- s/jedi.get_python_environment/jedi.get_system_environment: the former
does not exist (renamed in https://github.com/davidhalter/jedi/commit/336087f)
- improve error display
This basically corrupts VIM's Python, because it might be having a differnet prefix (Python 3.6) than sys path. I don't know who came up with this - probably it's just how Python loads venvs - but it's definitely not good. Fortunately we can just reset it and be happy.
Unlisted buffers might come e.g. from `set viminfo+=%`, and Jedi would
crash on them.
This could additionally check for them to be readable, but this should
be handled in Jedi itself anyway.
Move jedi_vim.py and the jedi submodule into pythonx, which gets added
to Vim's internal sys.path. While jedi cannot be imported directly from
there, it still makes sense for consistency.
