Vim terminal output broken after loading clang_complete (Cygwin)

[wilywampa]

For some reason loading clang_complete causes Vim's terminal output to look like the attached screenshot. The completion itself actually works fine. I can temporarily fix the problem by running :let &term = &term. There are no display/completion problems in gVim.

I am running in Cygwin and I updated everything and reinstalled all Clang-related packages today to no avail. I have tried mintty and xterm, multiple settings of $TERM (xterm, xterm-256color, screen-256color, dummy), and multiple versions of vim (7.417, 7.444, 7.487) but nothing has made any difference. vim-clang works without any problems but I prefer clang_complete.

Any ideas?

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 21 2014 13:58:30)
Included patches: 1-487
Compiled by Jake@jake-mbp-win
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl             +clientserver    +cscope          +emacs_tags      +folding         +keymap          +menu            +mouse_netterm   +netbeans_intg   -python3         -sniff           -tcl             +virtualedit     +writebackup
+arabic          +clipboard       +cursorbind      +eval            -footer          +langmap         +mksession       +mouse_sgr       +path_extra      +quickfix        +startuptime     +terminfo        +visual          +X11
+autocmd         +cmdline_compl   +cursorshape     +ex_extra        +fork()          +libcall         +modify_fname    -mouse_sysmouse  -perl            +reltime         +statusline      +termresponse    +visualextra     -xfontset
+balloon_eval    +cmdline_hist    +dialog_con_gui  +extra_search    +gettext         +linebreak       +mouse           +mouse_urxvt     +persistent_undo +rightleft       -sun_workshop    +textobjects     +viminfo         +xim
+browse          +cmdline_info    +diff            +farsi           -hangul_input    +lispindent      +mouseshape      +mouse_xterm     +postscript      +ruby            +syntax          +title           +vreplace        +xsmp_interact
++builtin_terms  +comments        +digraphs        +file_in_path    +iconv           +listcmds        +mouse_dec       +multi_byte      +printer         +scrollbind      +tag_binary      +toolbar         +wildignore      +xterm_clipboard
+byte_offset     +conceal         +dnd             +find_in_path    +insert_expand   +localmap        -mouse_gpm       +multi_lang      +profile         +signs           +tag_old_static  +user_commands   +wildmenu        -xterm_save
+cindent         +cryptv          -ebcdic          +float           +jumplist        +lua             -mouse_jsbterm   -mzscheme        +python          +smartindent     -tag_any_white   +vertsplit       +windows         +xpm
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/atk-1.0 -I/usr/include
/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng15 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/
usr/include/libpng15 -I/usr/include/freetype2 -I/usr/include/libpng15    -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L/usr/lib   -L. -fstack-protector  -L/usr/local/lib -Wl,--as-needed -o vim.exe   -L/usr/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lgio-2.0 -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -latk-1.0 -
lcairo -lz -lpixman-1 -lxcb-shm -lxcb-render -lXrender -lXext -lX11 -lxcb -lXau -lXdmcp -lgdk_pixbuf-2.0 -lm -lpng15 -lm -lz -lgio-2.0 -lz -lpangoft2-1.0 -lharfbuzz -lpango-1.0 -lm -lgmodule-2.0 -lgobject-2.0 -lffi -lglib-2.0 -lintl -lpcre
 -lintl -liconv -lpcre -lfontconfig -lexpat -lfreetype -lbz2 -lpng15 -lm -lz -lexpat -lfreetype -lbz2 -lz -lpng15 -lm -lz  -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -lncurses -lelf   -liconv -lintl  -L/usr/lib -llua  -L/usr/lib/p
ython2.7/config -lpython2.7 -ldl   -lruby200 -lpthread -lrt -ldl -lcrypt

[tobiasgrosser]

On 21.10.2014 23:11, wilywampa wrote:

For some reason loading clang_complete causes Vim's terminal output to look like the attached screenshot. The completion itself actually works fine. I can temporarily fix the problem by running |:let &term = &term|. There are no display/completion problems in gVim.

I am running in Cygwin and I updated everything and reinstalled all Clang-related packages today to no avail. I have tried mintty and xterm, multiple settings of |$TERM| (xterm, xterm-256color, screen-256color, dummy), and multiple versions of vim (7.417, 7.444, 7.487) but nothing has made any difference. vim-clang works without any problems but I prefer clang_complete.

Any ideas?

untitled https://cloud.githubusercontent.com/assets/4472522/4726864/52676b12-5966-11e4-801f-7ab2cb727f04.png

Not really. Did clang_complete work before for you? Could you check if an older version of clang_complete does not have these issues? If this is the case, we could try to bisect the problematic commit.

Tobias

[wilywampa]

Fortunately I had a different computer with an older Cygwin installation on which clang_complete does work. It appears that the latest version of libclang that ships with Cygwin is causing the problem. I have no clue what kind of change would cause this kind of problem.

To work around the problem, I downloaded libclang-3.1-3.tar.bz2 from here and pointed g:clang_library_path to it: http://mirror.mcs.anl.gov/cygwin/x86/release/llvm/libclang/

I also had to modify libclang.py because the include path for Cygwin libclang has changed from /usr/lib/clang/version/include to /usr/lib/clang/i686-pc-cygwin/version/include or /usr/lib/clang/x86-64-pc-cygwin/version/include.

The newer versions of libclang (3.4.2-1 and 3.4.2-3) have the problem I described. I should probably report this on the Cygwin mailing list but I have no clue how to even properly define the problem.

[tobiasgrosser]

On 22.10.2014 19:54, wilywampa wrote:

Fortunately I had a different computer with an older Cygwin installation on which clang_complete does work. It appears that the latest version of libclang that ships with Cygwin is causing the problem. I have no clue what kind of change would cause this kind of problem.

To work around the problem, I downloaded libclang-3.1-3.tar.bz2 from here and pointed |g:clang_library_path| to it: http://mirror.mcs.anl.gov/cygwin/x86/release/llvm/libclang/

OK.

I also had to modify libclang.py because the include path for Cygwin libclang has changed from /usr/lib/clang/|version|/include to /usr/lib/clang/i686-pc-cygwin/|version|/include or /usr/lib/clang/x86-64-pc-cygwin/|version|/include.

Could you submit a patch that adds this path?

The newer versions of libclang (3.4.2-1 and 3.4.2-3) have the problem I described. I should probably report this on the Cygwin mailing list but I have no clue how to even properly define the problem.

Sorry, no idea on my side either.

Tobias

[wilywampa]

I don't think that patch would be a good idea because the libclang installed by Cygwin does find its headers without that change, just not when I use an old DLL which had the headers somewhere else. A compiled a few versions of Clang from source and found that 3.3 works and 3.4 does not. The releases are too different to tell what change could cause this so I'm checking out the SVN repo and hopefully finding the exact revision where it broke. It's pretty slow to compile in Cygwin so this will take awhile.

[wilywampa]

Problem solved (after hours of compiling well into double digits, but solved nonetheless)!

Revision 188615 of llvm/lib/Support/Unix/Process.inc changed the way terminal capabilities are detected, and the new logic decides that colored terminal output is not available in Cygwin. Installing the libncurses-devel package and recompiling solves the problem (basically just following the directions here without skipping the part about colored diagnostics). I will post on the Cygwin mailing list with this information to hopefully solve the problem in a future distribution.

Still, no clue why libclang affects terminal settings when it's being used from Python bindings and not displaying anything on screen.

One additional minor issue that came up is getBuiltinHeaderPath expects and directory, but recently it became allowed to point g:clang_library_path to a specific file instead of just a directory. I will submit a pull request for that issue.

[wilywampa]

The pull request to fix library_path is here: https://github.com/Rip-Rip/clang_complete/pull/424

[wilywampa]

I must have gotten confused about what version I was building and the above information is wrong. libncurses-devel doesn't seem to make a difference. What does fix the problem is using --enable-terminfo=no for the configure script or -DLLVM_ENABLE_TERMINFO=OFF if you build with cmake.