Notes on .clang_completeEdit
The compiler switches in .clang_complete are not the same as on the command-line. For a fresh test-project I am able to compile my file via
clang++ main.cpp -c -v but a plenty of more details need to be put into .clang_complete (in my case).
The best way - in my opinion - to create a .clang_complete file is to make your file/projekt compile on the command line and then enable verbose output via '-v':
my@suse:~/home/my/test> clang++ main.cpp -c -v -fno-color-diagnostics -fdiagnostics-format=vi
clang version 3.0 (tags/RELEASE_30/final)
Thread model: posix
/home/my/src/llvm/build_3.0/Release/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 11.2 -momit-leaf-frame-pointer -v -coverage-file main.o -resource-dir /home/my/src/llvm/build_3.0/Release/bin/../lib/clang/3.0 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../include/c++/4.4 -internal-isystem /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../include/c++/4.4/x86_64-suse-linux -internal-isystem /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../include/c++/4.4/backward -internal-isystem /usr/local/include -internal-isystem /home/my/src/llvm/build_3.0/Release/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include -fdeprecated-macro -ferror-limit 19 -fmessage-length 213 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fdiagnostics-format vi -o main.o -x c++ main.cpp
... (further outputs) ...
The contents that are marked bold should be put into .clang_complete. The paths - of course - should be prepended by -I. So the resulting .clang_complete file will look like this:
-I /usr/include/c++/4.4 -I /usr/include/c++/4.4/x86_64-suse-linux -I /usr/include/c++/4.4/backward -I /usr/local/include -I /home/my/src/llvm/build_3.0/Release/lib/clang/3.0/include -I /usr/include -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fdiagnostics-format vi
Couldn't the clang parser also be used to improve the taglist plugin? script#273
I thinks tab taglist is a great tool. However, it has problems with advanced C++ code. --Michael.lehn 17 November 2011
- Have you tried Tagbar? It specifically aims for better C++ support that Taglist, but is similar in many ways. --Fritzophrenic 15:23, November 21, 2011 (UTC)
Hi, Does anyone know how to get list of overloaded functions when we use clang_complete? I can only see one of the overloaded functions in the autocomplete popup window.
clang_complete is not completing code after the period (.) it does work well for a pointer(->). e.g.:
my_struct_t *pointer, nonpointer; pointer-> // COMPLETES fine nonpointer. // DOES NOT complete
Any ideas? Thanks --August 10, 2016
If you have <CR> bound to anything this plugin will override that.
Not Clear Where to Get Latest VersionEdit
This is a bug report, sorry if it should be elsewhere. The versioning is messy. The vim scripts page says to use version 2.8 or later, but the latest one on that page is 2.0. The git hub only has one release, and its version 1.8. Its also a good idea to mention on the vim scripts page how to get the latest version with a git invocation from the command line. And really in my mind for the work that goes into the script you might as well keep the latest release on the scripts page up to date.
Can't Tell if I'm Running ItEdit
I thought all vim scripts went in ~/.vim but I guess not this one since the page say something about alternatively copying things there (though it doesn't say where, or what it normally does instead), and I couldn't find any files matching "*clang*" under .vim, and the help doesn't work from within vim (which is why I was looking). I hit tab in insert mode and it does useful stuff though.