davidhalter
commented
6 years ago @blueyed Is there any way we can get that traceback? Is this an issue with his VIM or a general one?
Closed reallyohwell closed 6 years ago
davidhalter
commented
6 years ago @blueyed Is there any way we can get that traceback? Is this an issue with his VIM or a general one?
blueyed
commented
6 years ago Is there any way we can get that traceback?
Maybe when printing it.. but it gets lost usually.
@reallyohwell
The code is https://github.com/davidhalter/jedi-vim/blob/37bd03c3d575be6126369937ef242a259088a137/autoload/jedi.vim#L157-L163.
I.e. try running :py3 import jedi_vim manually.
It looks like it may come from :py3 import vim though.
reallyohwell
commented
6 years ago On a freshly booted machine, I entered 'gvim ~/t.py'. Same problem. Oddly, :py3 jedi-vim does seem to work, but ctrl-space still won't work. I tried :so ~/.vim/bundle/jedi-vim/autoload/jedi.vim and it seemed to work. But no ctrl-space, so the plugin is not working. However I do seem to remember issuing that same statement yesterday only to have it give the error. I might be confused about this. This is a classic intermittent situation, like the television that never acts up in the shop, but always acts up in the person's house. It ain't the water pipes causing it. These things never make sense until something allows one to pin down the issue.
reallyohwell
commented
6 years ago On a freshly booted machine, I entered 'gvim ~/t.py'. Same problem. Oddly, :py3 jedi-vim does seem to work, but ctrl-space still won't work. I tried :so ~/.vim/bundle/jedi-vim/autoload/jedi.vim and it seemed to work. But no ctrl-space, so the plugin is not working. However I do seem to remember issuing that same statement yesterday only to have it give the error. I might be confused about this. This is a classic intermittent situation, like the television that never acts up in the shop, but always acts up in the person's house. It ain't the water pipes causing it. These things never make sense until something allows one to pin down the issue.
reallyohwell
commented
6 years ago I think I can pin down the problem better now.
How to get it to not work: 1: Start [g]vim with an active tab with a .py file. Jedi-vim tries to autoload, and acts up. 2: Start [g]vim without an active .py file tab, then open a .py file. jedi-vim tries to autoload, and acts up.
How to get it to work: 1: Start [g]vim without an active .py file tab, which will not try to autoload jedi-vim. Then enter :py3 exec('import vim; import jedi_vim'), then enter :call jedi#setup_py_version(3), then open a .py file. At that point, ctrl-space seems to work.
I tried to run the vim debugger on :debug call jedi#init_python(). Oddly, it seemed to act up in line 165 of jedi.vim, which is the one that does the imports that worked above.
So there is certainly something funny going on here.
davidhalter
commented
6 years ago Since this is something that doesn't happen to other users,I suspect that something is wrong with your environment/compilation of VIM. Since you're running it inside Gentoo, I'm not sure how many people have tested that before. Whatever you're finding, please let us know here.
reallyohwell
commented
6 years ago Another data point: if I run
D=~/.vim/bundle/jedi-vim; S=_jedi; gvim -i ${D}/.viminfo${S} -c "so ${D}/.sess${S}" -c "py3 exec('import vim; import jedi_vim')" -c "call jedi#init_python()" 2>/dev/null &
then the editor comes up, but if I open a .py file, I get the problem. But if I enter the above command and then enter :call jedi#init_python(), then open a .py file, it works. This behavior does not seem to make sense. Are you sure this isn't a jedi_vim problem?
Also, I noticed that jedi#reinit_python() doesn't seem to work. It unlets s:_init_python, and jedi#init_python() expects a value there, so it blows up.
davidhalter
commented
6 years ago I'm not saying I'm sure. I'm pretty sure that there are still jedi-vim bugs. The odds are just stacked against you, because it's running for everyone else. But it could even be something that a newer VIM version does different. I'm still on a version that is a few years older.
blueyed
commented
6 years ago @reallyohwell
I noticed that jedi#reinit_python() doesn't seem to work
Yeah, noticed this myself earlier, and started to fix it back then - need to create a PR for it.
Some more debugging hint:
:verb com PythonJedi (should be python3):let g:jedi#force_py_version = 3 help? (to skip trying to use py2, which you do not have)PythonJedi import vim and PythonJedi import jedi_vim (removing the try/except etc). This should hopefully give you the full traceback.reallyohwell
commented
6 years ago 1: says python3 2: I put this in .vimrc, and it did nothing. 3: I did this, but it still gives a generic message, not a full traceback.
In the function jedi#reinit_python() I changed the unlet to a let to -1. The function runs, but it won't fix a broken ctrl-space.
But I by accident found something else that seems to work. If I start the editor like this:
T=_python-www; gvim -i ./.viminfo${T} -S ./.sess${T} -c "py3 exec('import vim; import jedi_vim')" 2>/dev/null &
I get the problem, and jedi#reinit_python() runs but won't fix it.
If I run the editor without the -S part (which does not reload a session), then issue :so .sess_python-www from within the editor, then it works.
If I take out the vim and jedit-vim imports above, it acts up when I source the session, and jedi#reinit_python() runs but does not fix the problem.
When I started the editor without the imports, then issued :pye import vim; import jedi_vim, then source the session file, it threw a bunch of session file errors the first time, then worked the second time.
So it looks like there is some problem here with the way this plugin initializes while files are being loaded. There are so many things going on in this editor that these plugins, autocmds, etc. start tripping over each other's shoelaces. SessionMan is also acting up on this machine, but not my other gentoo 32 bit machine.
I tried to turn off as many compile switches (i.e., gentoo use switches) as possible and recompile. No effect. I don't think this is just a gentoo thing.
blueyed
commented
6 years ago Yeah, sessions might cause trouble. So you are using SessionMan for session management by default?
reallyohwell
commented
6 years ago I was loading SessionMan but not using it. It marks all open tabs as modified. Not good. I dragged SessionMan away from .vim/bundle to make sure it is not in use. Same problem.
It not the fault of :so .sess -- the same thing happens if I open any python file off the command line.
I put some debug statements in all the main functions - I think. Here is what I got on editor startup.
"after/ftplugin/python/jedi.vim" 3L, 121C
"ftplugin/python/jedi.vim" 52L, 1925C
"~/t.py" 7L, 60C
Entering file autoload/jedi.vim
Entering function autoload/jedi.vim/jedi#init_python()
Entering function autoload/jedi.vim/init_python()
Entering function autoload/jedi.vim/jedi#setup_py_version()
Error detected while processing function jedi#init_python:
line 8:
Error: jedi-vim failed to initialize Python: Vim(python3):Traceback (most recent call last): (in function jedi#init_python[4]..<SNR>76_init_python[51]..jedi#setup_py_version, line 24)
Entering function autoload/jedi.vim/jedi#init_python()
Entering file ftplugin/python/jedi.vim
Entering function autoload/jedi.vim/jedi#init_python()
Entering function autoload/jedi.vim/jedi#init_python()
"test/documentation.vim" 31L, 599C
"~/.vim/config/vimrc_general" 109L, 2401C
Entering function autoload/jedi.vim/jedi#init_python()I kept putting debug statements into that import jedi-vim section shown above, and I'm getting a strange result. I put the code at https://pastebin.com/97GkwNAK.
Apparently it is acting up at the import jedi-vim statement, but here is what's funny: the Except block is not being called. That is why I got the generic exception code I mentioned above. The s:init_outcome is not being overwritten with anything - it still contains 0.
I put another level of Except: in there but it does nothing. The outer Except: block is not executing.
Strangely, if I put a finally: block in there, it does execute, but that change makes jedi#init_python() run and fail every time I try to make any change to a .py file.
Shouldn't that Except: block be executing?
davidhalter
commented
6 years ago Can you maybe do an except BaseException? Exception doesn't include all errors.
reallyohwell
commented
6 years ago I tried BaseException but nothing changed. If I take out the import jedi-vim line, it will fail because init_outcome is 0, but the python exception is not thrown. Instead, this error starts showing up:
Error detected while processing command line: /usr/lib64/python3.5/site-packages/sphinx/util/compat.py:40: RemovedInSphinx17Warning: sphinx.util.compat.Directive is deprecated and will be removed in Sphinx 1.7, please use docutils' instead. RemovedInSphinx17Warning)
It appears that a python exception is being thrown directly up to the vimscript level, which is not what is intended. There must be some bug in the vim-python interfacing. In this case , that bug is preventing this plugin from saying what its bug is all about.
regisz
commented
6 years ago Hi, I think, I got the same issue but with py2. The error message:
Error detected while processing function jedi#init_python:
line 7:
Error: jedi-vim failed to initialize Python: jedi#setup_python_imports: could not import jedi_vim: SyntaxError: invalid syntax (jedi_vim.py, line 25). (in function jedi#init_python[3]..SNR>53_init_python[2]..jedi#setup_python_imports, line 30)
Error: jedi-vim failed to initialize Python: jedi#setup_python_imports: could not import jedi_vim: SyntaxError: invalid syntax (jedi_vim.py, line 25). (in function jedi#init_python[3]..SNR>53_init_python[2]..jedi#setup_python_imports, line 30)$ vim --version:
VIM - Vi IMproved 8.1 (2018 May 17, compiled Jun 19 2018 13:26:45)
Compiled by balage
Huge version without GUI. Features included (+) or not (-):
+acl +farsi +mouse_sgr -tag_any_white
+arabic +file_in_path -mouse_sysmouse -tcl
+autocmd +find_in_path +mouse_urxvt +termguicolors
+autoservername +float +mouse_xterm +terminal
-balloon_eval +folding +multi_byte +terminfo
+balloon_eval_term -footer +multi_lang +termresponse
-browse +fork() -mzscheme +textobjects
++builtin_terms +gettext +netbeans_intg +timers
+byte_offset -hangul_input +num64 +title
+channel +iconv +packages -toolbar
+cindent +insert_expand +path_extra +user_commands
-clientserver +job -perl +vertsplit
-clipboard +jumplist +persistent_undo +virtualedit
+cmdline_compl +keymap +postscript +visual
+cmdline_hist +lambda +printer +visualextra
+cmdline_info +langmap +profile +viminfo
+comments +libcall +python/dyn +vreplace
+conceal +linebreak +python3/dyn +wildignore
+cryptv +lispindent +quickfix +wildmenu
+cscope +listcmds +reltime +windows
+cursorbind +localmap +rightleft +writebackup
+cursorshape -lua -ruby -X11
+dialog_con +menu +scrollbind -xfontset
+diff +mksession +signs -xim
+digraphs +modify_fname +smartindent -xpm
-dnd +mouse +startuptime -xsmp
-ebcdic -mouseshape +statusline -xterm_clipboard
+emacs_tags +mouse_dec -sun_workshop -xterm_save
+eval -mouse_gpm +syntax
+ex_extra -mouse_jsbterm +tag_binary
+extra_search +mouse_netterm +tag_old_static
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/home/balage/.local/share/vim"
Compilation: gcc -std=gnu99 -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -std=gnu99 -L/usr/local/lib -Wl,--as-needed -o vim -lm -ltinfo -lnsl -ldl$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.11 (wheezy)
Release: 7.11
Codename: wheezy@regisz
SyntaxError: invalid syntax (jedi_vim.py, line 25).
Are you using Python 2.6?
blueyed
commented
6 years ago @regisz After all you have a different issue, please create a new issue if it persists - i.e. you are not using 2.6 (which is not supported anymore).
blueyed
commented
6 years ago @reallyohwell
Error detected while processing command line: /usr/lib64/python3.5/site-packages/sphinx/util/compat.py:40: RemovedInSphinx17Warning: sphinx.util.compat.Directive is deprecated and will be removed in Sphinx 1.7, please use docutils' instead. RemovedInSphinx17Warning)
Maybe something like python -W error is used somewhere, i.e. it turns warnings into errors?
regisz
commented
6 years ago ok, I made a new issue: https://github.com/davidhalter/jedi-vim/issues/833
blueyed
commented
6 years ago Closing this due to feedback / moved into separate issues.
artem0
commented
5 years ago Hey, I'm experiencing this issue again: Error detected while processing function jedi#init_python[4]..<SNR>102_init_python[27]..jedi#setup_python_imports despite I have a proper python 2.7.
blueyed
commented
5 years ago @artem0 Please file a new issue with more / required / asked for info.
Issue
I have two machines -- a gentoo 64 bit and a gentoo 32 bit.
I also have the problem: Error detected while processing function jedi#init_python: line 7: Error: jedi-vim failed to initialize Python: jedi#setup_py_version: failed to run Python for initialization: Vim(python3):Traceback (most rece nt call last):. (in function jedi#init_python[3]..69_init_python[50]..jedi#setup_py_version, line 25)
Here is what is funny. Vim-jedi seems to work on the 32 bit machine. I just git-cloned into ~/.vim/bundle.
On the 64 bit machine I was fooling around with vim and to my surprise for the first time I could start gvim with no arguments without the above message. Then to my surprise I could type in a tiny file ~/t.py that printed the sys.path. The vim-jedi completion worked for the first time.
Then I did a little test: leave the editor and type gvim ~/t.py to reenter. To my surprise there was no message, and the line completion worked.
After that, vim-jedi quit working in the smae manner. The same message comes up when t.py is edited, either by 'gvim ~/t.py' or by :e ~/t.py.
When I said "fooling around" above, what I am really saying is that I don't know of anything I did to make vim-jedi start working, and I don't know of anything I did to make jedi-vim stop working. But I'm pretty sure I that I am accurately describing what happened.
So it appears that there is indeed some subtle bug that could be on the vim side. Or it could be on the python side. The combination of vim and python does not seem to be acting in a deterministic fashion. That kind of argues against the usual "configuration error" scenario. It is something else.
Is there any way to debug the python code called by vim?
Thanks in advance.
Steps to reproduce
As I said above, the lack of any steps is the real point.
My .vimrc:
let PathVimConfig = "/home/me/.vim/config/"
" VIM.Plugin.Pathogen " This command says to load ~/.vim/autoload/pathogen.vim and run infect(). " execute pathogen#infect() call pathogen#helptags()
set nocompatible
let script_dir = fnamemodify(expand(''), ':h')
let &runtimepath .= ','.script_dir.','.script_dir.'/after'
" Put your config changes here. " let g:jedi#show_call_signatures=1
syntax on filetype plugin indent on
Output of “:verbose JediDebugInfo”
You should run this in a buffer with filetype "python".
Jedi-vim debug information
Using Python version: 3
3.5.4 (default, Jan 17 2018, 01:42:35), [GCC 6.4.0]/usr/lib64/python3.5/site.pyJedi path:/home/me/.vim/bundle/jedi-vim/pythonx/jedi/jedi/__init__.py/usr/lib64/python35.zip/usr/lib64/python3.5/usr/lib64/python3.5/plat-linux/usr/lib64/python3.5/lib-dynload/home/me/.local/lib64/python3.5/site-packages/usr/lib64/python3.5/site-packages_vim_path_Settings
:version
:messages
:scriptnames
``` 1: /etc/vim/vimrc 2: /usr/share/vim/vim80/syntax/syntax.vim 3: /usr/share/vim/vim80/syntax/synload.vim 4: /usr/share/vim/vim80/syntax/syncolor.vim 5: /usr/share/vim/vim80/filetype.vim 6: /usr/share/vim/vimfiles/ftdetect/cmake.vim 7: /usr/share/vim/vimfiles/ftdetect/gentoo.vim 8: /usr/share/vim/vimfiles/ftdetect/llvm-lit.vim 9: /usr/share/vim/vimfiles/ftdetect/llvm.vim 10: /usr/share/vim/vimfiles/ftdetect/meson.vim 11: /usr/share/vim/vimfiles/ftdetect/tablegen.vim 12: /usr/share/vim/vim80/menu.vim 13: /usr/share/vim/vim80/autoload/paste.vim 14: /usr/share/vim/vim80/ftplugin.vim 15: ~/.vimrc 16: ~/.vim/autoload/pathogen.vim 17: /usr/share/vim/vim80/ftoff.vim 18: /usr/share/vim/vim80/syntax/nosyntax.vim 19: /usr/share/vim/vim80/indent.vim 20: ~/.vim/bundle/bufexplorer.vim/plugin/bufexplorer.vim 21: ~/.vim/bundle/ctrlp/plugin/ctrlp.vim 22: ~/.vim/bundle/ctrlp/autoload/ctrlp/mrufiles.vim 23: ~/.vim/bundle/jedi-vim/plugin/jedi.vim 24: ~/.vim/bundle/nerdtree/plugin/NERD_tree.vim 25: ~/.vim/bundle/nerdtree/autoload/nerdtree.vim 26: ~/.vim/bundle/nerdtree/lib/nerdtree/path.vim 27: ~/.vim/bundle/nerdtree/lib/nerdtree/menu_controller.vim 28: ~/.vim/bundle/nerdtree/lib/nerdtree/menu_item.vim 29: ~/.vim/bundle/nerdtree/lib/nerdtree/key_map.vim 30: ~/.vim/bundle/nerdtree/lib/nerdtree/bookmark.vim 31: ~/.vim/bundle/nerdtree/lib/nerdtree/tree_file_node.vim 32: ~/.vim/bundle/nerdtree/lib/nerdtree/tree_dir_node.vim 33: ~/.vim/bundle/nerdtree/lib/nerdtree/opener.vim 34: ~/.vim/bundle/nerdtree/lib/nerdtree/creator.vim 35: ~/.vim/bundle/nerdtree/lib/nerdtree/flag_set.vim 36: ~/.vim/bundle/nerdtree/lib/nerdtree/nerdtree.vim 37: ~/.vim/bundle/nerdtree/lib/nerdtree/ui.vim 38: ~/.vim/bundle/nerdtree/lib/nerdtree/event.vim 39: ~/.vim/bundle/nerdtree/lib/nerdtree/notifier.vim 40: ~/.vim/bundle/nerdtree/autoload/nerdtree/ui_glue.vim 41: ~/.vim/bundle/nerdtree/nerdtree_plugin/exec_menuitem.vim 42: ~/.vim/bundle/nerdtree/nerdtree_plugin/fs_menu.vim 43: ~/.vim/bundle/sessionman/plugin/sessionman.vim 44: ~/.vim/bundle/tagbar/plugin/tagbar.vim 45: /usr/share/vim/vimfiles/plugin/gentoo-common.vim 46: /usr/share/vim/vimfiles/plugin/newebuild.vim 47: /usr/share/vim/vimfiles/plugin/newinitd.vim 48: /usr/share/vim/vimfiles/plugin/newmetadata.vim 49: /usr/share/vim/vim80/plugin/getscriptPlugin.vim 50: /usr/share/vim/vim80/plugin/gzip.vim 51: /usr/share/vim/vim80/plugin/logiPat.vim 52: /usr/share/vim/vim80/plugin/manpager.vim 53: /usr/share/vim/vim80/plugin/matchparen.vim 54: /usr/share/vim/vim80/plugin/netrwPlugin.vim 55: /usr/share/vim/vim80/plugin/rrhelper.vim 56: /usr/share/vim/vim80/plugin/spellfile.vim 57: /usr/share/vim/vim80/plugin/tarPlugin.vim 58: /usr/share/vim/vim80/plugin/tohtml.vim 59: /usr/share/vim/vim80/plugin/vimballPlugin.vim 60: /usr/share/vim/vim80/plugin/zipPlugin.vim 61: /etc/vim/gvimrc 62: ~/.vim/config/.sess 63: /usr/share/vim/vim80/ftplugin/vim.vim 64: /usr/share/vim/vim80/syntax/vim.vim 65: /usr/share/vim/vim80/syntax/perl.vim 66: /usr/share/vim/vim80/syntax/pod.vim 67: /usr/share/vim/vim80/syntax/ruby.vim 68: /usr/share/vim/vim80/syntax/python.vim 69: /usr/share/vim/vim80/indent/vim.vim 70: ~/.vim/bundle/ctrlp/autoload/ctrlp/utils.vim 71: /usr/share/vim/vim80/scripts.vim 72: ~/.vim/bundle/tagbar/autoload/tagbar.vim 73: ~/.vim/bundle/tagbar/autoload/tagbar/debug.vim 74: ~/.vim/bundle/jedi-vim/ftplugin/python/jedi.vim 75: ~/.vim/bundle/jedi-vim/autoload/jedi.vim 76: /usr/share/vim/vim80/ftplugin/python.vim 77: ~/.vim/bundle/jedi-vim/after/ftplugin/python/jedi.vim 78: ~/.vim/bundle/jedi-vim/after/syntax/python.vim 79: /usr/share/vim/vim80/indent/python.vim ```