Closed Mizuchi closed 11 years ago
Is there something in particular that doesn't work for you? It seems to run just fine on my machine.
I tried it, but I didn't succeed. I have compiled vim with python3 support and used 2to3 to convert clang_complete to python3. Unfortunately, I still get the following error messages:
@crsqq, did you update condition at this line. I guess you need to test for python3
feature there.
Well, if I change that if condition to check for python3, I get some other error messages (see screenshot below). It seem as if one has to rewrite the function "initClangCompletePython" has to make clang_complete compatible with python3. @jstasiak You wrote, that it runs fine on your machine. What kind of changes have you made to make it run?
//edit After changing some more python's and py's to there python3 equivalent I got rid of the error messages above. Unfortunately I got some new errors:
I didn't know that there is a dedicated command to use python3. You probably need to change all occurrences of python
to python3
and py
to py3
in clang_complete.vim
file (they are present outside initClangCompletePython
function too).
Apparently getting clang_complete working with python3 is not as easy as I thought. I'll take a closer look at that in the next few days.
@crsqq Unfortunately i don't remember what my setup was at the time right now. Regarding https://cloud.githubusercontent.com/assets/4514040/3075450/a50e6b86-e378-11e3-8cfd-9c5c15ce60a1.png - would you mind modifying cindex.py
from
unsaved_array[i].name = name
to
print(repr([i, unsaved_array[i], unsaved_array[i].name, name]))
unsaved_array[i].name = name
and providing the output? I don't really know clang_complete code but this should shed some light on the issue.
In the second line you can see the output of the print statement.
I think the problem is, that ctypes expects something of type byte
but since the change to unicode with python3 it gets something of type string
. If that's the cause of the problem I don't know how to fix this in a comfortable way because ctype functions are used quiet often.
This is marked as closed, but I just hit the same issue when compiling (g)vim with python 3 support. Is it believed to be solved, or just marked as closed and "won'tfix"?
I recently recompiled my system and tried to move to Python 3 world, but it seems there are some issues with it. For Vim, I had to choose one specific python version (the Gentoo package complains that a single one needs to be specified), so I went with Python 3.3. That removes the Python 2.7 support, so my :version looks like:
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun 23 2014 21:52:32)
Inkluderade patchar: 1-326
Modifierad av Gentoo-7.4.326
Kompilerad av peter@skare
Enorm version utan GUI. Funktioner inkluderade (+) eller inte (-):
+acl +farsi +mouse_netterm +syntax
+arabic +file_in_path +mouse_sgr +tag_binary
+autocmd +find_in_path -mouse_sysmouse +tag_old_static
-balloon_eval +float +mouse_urxvt -tag_any_white
-browse +folding +mouse_xterm -tcl
++builtin_terms -footer +multi_byte +terminfo
+byte_offset +fork() +multi_lang +termresponse
+cindent +gettext -mzscheme +textobjects
+clientserver -hangul_input +netbeans_intg +title
+clipboard +iconv +path_extra -toolbar
+cmdline_compl +insert_expand +perl +user_commands
+cmdline_hist +jumplist +persistent_undo +vertsplit
+cmdline_info +keymap +postscript +virtualedit
+comments +langmap +printer +visual
+conceal +libcall +profile +visualextra
+cryptv +linebreak -python +viminfo
-cscope +lispindent +python3 +vreplace
+cursorbind +listcmds +quickfix +wildignore
+cursorshape +localmap +reltime +wildmenu
+dialog_con -lua +rightleft +windows
+diff +menu -ruby +writebackup
+digraphs +mksession +scrollbind +X11
-dnd +modify_fname +signs +xfontset
-ebcdic +mouse +smartindent -xim
+emacs_tags -mouseshape -sniff +xsmp_interact
+eval +mouse_dec +startuptime +xterm_clipboard
+ex_extra +mouse_gpm +statusline -xterm_save
+extra_search -mouse_jsbterm -sun_workshop -xpm
system-vimrc-fil: "/etc/vim/vimrc"
användar-vimrc-fil: "$HOME/.vimrc"
Andra användar-vimrc-fil: "~/.vim/vimrc"
användar-exrc-fil: "$HOME/.exrc"
reserv för $VIM: "/usr/share/vim"
Kompilering: x86_64-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H -march=native -O2 -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Länkning: x86_64-pc-linux-gnu-gcc -Wl,-E -L/usr/local/lib -Wl,--as-needed -o vim -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lelf -lnsl -lacl -lattr -lgpm -ldl -Wl,-E -Wl,--as-needed -L/usr/lib64/perl5/5.18.2/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lc -L/usr/lib64/python3.3/config-3.3 -lpython3.3 -lpthread -ldl -lutil -lm
Now in Debian testing, vim package is also compiled with only python3 support.
that's a bold move, does debian have any reason for dropping the python2 support?
Seems to be a decision of the package maintainer. Here's a bug report about the suppressed feature on the official package tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839903
From the bug report:
Both Python and Python3 can't be enabled at the same time, so one has to be chosen.
It's not true (--enable-pythoninterp=dynamic --enable-python3interp=dynamic
):
$ src/vim --version | grep python
+cryptv +linebreak +python/dyn +vreplace
+cscope +lispindent +python3/dyn +wildignore
Debian maintainer argues against loading python dynamically and has decided to switch from python2 to python3 with the release of Vim8
So it doesn't work in Debian because of the way dependencies are managed and python is built there. Anyway, I just wanted to point out that Vim is able to do this in principle and "both Python and Python3 can't be enabled" is not the correct way of saying it.
"both Python and Python3 can't be enabled" ... I never said that ;-)
I know, they did. As for the issue, I think it should be possible to make the plugin compatible with both versions of python, but I don't have any experience doing this.
@xaizek In another issue session #430, @myint mentioned he add python 3 support for clang_complete. but I'm not sure if his solution still compatible with the current clang_complete.
Thanks @jsfaint, I forgot about that fork already. See support-python3
branch. I didn't test it much, but it seems to work with both versions of python. After several people confirm that it works for them, we can merge it into master
.
@xaizek The completion not works on macvim with the following config.
But the map ctrl+]
works.
NeoBundle 'rip-rip/clang_complete', {'disabled': !(has('python') || has('python3'))}
"clang_complete
if neobundle#is_installed('clang_complete')
let g:clang_auto_select = 1
let g:clang_hl_errors = 1
let g:clang_complete_copen = 1
let g:clang_close_preview = 1
if has('mac')
let s:clang_library_path="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib"
if isdirectory(s:clang_library_path)
let g:clang_library_path=s:clang_library_path
endif
endif
endif
I'll try it on windows tomorrow.
@jsfaint, thanks, missed useful change for sorted()
builtin. Updated the branch.
@xaizek Thanks for your quick fix, it works now 👍
I have not done intensive tests but it seems to work with vim8 on Debian testing. THX for the fix.
Hi @xaizek I already use support-python3
branch for daily work over 1 month, everything works well.
But I noticed a little thing, when using the support-python3
branch, the command-line will print some message which is not happen in the master.
Maybe it's some debugging message?
And another question, do you have any plan to merge support-python3
into master
branch?
Thank you~
@Jsfaint, thanks, that was indeed a debug print statement that I forgot to remove, thanks. Removed that and merged it into master
.
@xaizek Thank you~ 👍
Have plans to do a python3 support? I tried 2to3 but does not work.