You are not logged in.
I have been using clang_complete (https://github.com/Rip-Rip/clang_complete) with vim for a while and after a recent upgrade, it started having some serious display issues when clang_complete is used (it works fine for non-C sources). My suspicion is about the ncurses 5.9-7 -> 6.0-3 upgrade from the past few days which is now in the stable repository. I have seen this on 3 different archlinux systems where it no longer works.
I have a gentoo system with ncurses 6.0 and the same version of clang_complete and vim 7.4.827 and it is working fine so I'm not sure if anyone else is experiencing this on archlinux.
Here's a screenshot of my gentoo system on the left and arch system on the right:
It is noticeable that the colors are gone and the airline bar that is supposed to be at the bottom is somehow at the top.
Things get much worse when you try to actually do some text editing or incremental scrolling where garbage starts popping up everywhere.
I am more suspicious that it is due to ncurses or readline since when I run vim as gvim with a GTK+ user interface on the same broken arch systems, everything works fine with clang_complete.
Offline
Also confirmed similar problems here.
There are three conditions (for me) to trigger the issue:
1. ncurses 6.0
2. some vim highlighting plugins like 'bbchung/clighter' or 'jeaye/color_coded'
3. edit a C/C++ source file in terminal (which will actually use the plugin mentioned above)
Then, the display is screwed up: http://postimg.org/image/h81qhib5x/
(You may find I'm using tmux with a fancy status bar. It has nothing to do with the bug. Even without tmux I can still see the same issue.)
Either disabling the plugin or downgrading ncurses to 5.9 (and also the dependent packages) will solve the problem. Considering the plugin and vim (despite the rebuild for ncurses 6.0) didn't change, I suspect the problem is related to ncurses 6.0.
Offline
I believe I have found that it is a problem with LLVM when it is built with ncurses support. My Gentoo system had LLVM built without ncurses support and I rebuilt it with ncurses support and it started behaving just like the archlinux version.
Offline
Weird enough. Why llvm has anything to do with ncurses? Especially these plugins are simply using llvm/clang as a library; and those library calls theoretically shouldn't interact with terminal I/O.
My original thought was more about the advanced highlighting of these plugins.
Offline
Same problem here.
Although you mentioned downgrading ncurses, but I failed to downgrade it as even only bash/readline has direct dependency on it,
if I downgrade ncurses to 5.9, vim will also fails to start as latest vim is using ncurse 6.0, need recompile to fix it.
The current workaround is using gvim, as it's still OK and unaffected, no need to recompile.
But I'm using vim not gvim to get the background transparent, so not a perfect solution though.
Offline
FWIW, recompiling clang with --disable-terminfo makes vim-clang-complete work again.
Offline
The issue is tracked here as well https://github.com/Rip-Rip/clang_complete/issues/453
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
FWIW, recompiling clang with --disable-terminfo makes vim-clang-complete work again.
Does it work if you simply recompile clang with the up-to-date ncurses (i.e. 6.0), leaving the terminfo enabled? In other words, is it an API compatibility problem how clang uses ncurses, or is it just a linking (ABI compatibility) problem?
Offline
Does it work if you simply recompile clang with the up-to-date ncurses (i.e. 6.0), leaving the terminfo enabled? In other words, is it an API compatibility problem how clang uses ncurses, or is it just a linking (ABI compatibility) problem?
OK. So recently there's a newly compiled llvm/clang rolling out (for some other reasons), and the problem still exists.
Last edited by Hexcles (2015-09-28 20:42:39)
Offline
Got a weird (but working!) workaround: redirecting stderr to a file or /dev/null solves the problem! i.e. start your vim with "vim 2>/dev/null".
Yet no one seems to understand why this is the case, since if you redirect the stderr to a file, you will see it is literally empty (0 byte)...
Offline
