roxma / ncm-clang Goto Github PK

Lsp is still have some weird problem

After buffer enter. spawn a clang process. feed until the last include statement to clang stdin. wait until cm_refresh. then feed the rest of the buffer.
I’m not sure this is going to work. Let keep this issue until I have time to work on it.

Initialized empty Git repository in /usr/local/data/zhongwenyi/.local/share/nvim/|~
error: while accessing https://git::@github.com/roxma/ncm-clang.git/info/refs | |~
fatal: HTTP request failed

How to solve this problem.

I have a compile_commans.json in my project's root path, but ncm-clang can not read it. As shown in these pictures, if it can find the include path, it can give the completion of testing, but it didn't. The project can be built, so the compiler can find the include file "gtest/gtest.h", so it should be ncm-clang didn't find the databash file.

Hi

It seems that this plugin only works if compile_commands.json is in the root directory or in root/build of the project. Could you please add the ability to specify the path for compile_commands or add some kind of search filter.

This problem because when you do crosscompiling and for example have multiple output folders like build/linux/ or build/arm/

I see in the screenshot you have parameter completion for functions, how did you achieve that? I tried, without luck, is there any variable should be configured?

Dear owner,
Thanks for providing us such a good plugin for Neovim! I appreciate your work deeply!

However, during my everyday usage of this plugin, I'm really distracted by the significant lag. And I would like to discuss with the community of the performance of ncm-clang. In my current project with more than one hundred of header files, YouCompleteMe gives result in around 1 second, while ncm-clang is around 5 second. I'm not sure what the reason is, but from what I have seen, I doubt the lag roots in the architecture of ncm-clang.

I was using YouCompleteMe for a long time. YouCompleteMe is a great project, except it's hard to compile on non-standard systems, e.g., MSYS2 on Windows. It needs to link with boost and libclang in order to work. And it finally generates a server-side binary for interacting with libclang, and a client-side python library which is loaded when a c/cpp file is opened. So, once a completion request is posted, vim could invoke the function in python client, and the client would send async request to the server. This work flow is high efficient in OS point-of-view, because the server is a persistent process, and OS may be able to cache the headers for the process. And no dynamic library or executables needs to be loaded in every completion.

On the other hand, what I see from my limited usage of ncm-clang is that, it calls clang every time when a completion request is emitted. Though this make it easier for installing the plugin (need not to build against libclang, etc), it slows down the processing of completion, with the overhead of a lot loading and initialization works per completion.

like .ycm_extra_conf.py in YCM.

YCM looks for a .ycm_extra_conf.py file in the directory of the opened file or in any directory above it in the hierarchy (recursively);

Even better if can support system environment variables in .clang_complete

ncm-lang fails to find completion arguments when you use ccache on compile_commands.json. In my case, I am generating compile_commands.json with Meson build system that automatically detects ccache.

Example compile_commands.json:

[
  {
    "directory": "/home/ismael/Repos/timesh/build",
    "command": "ccache c++  -Itest@exe -I. -I.. -I../include -Isrc -I../src -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++11 -O3 -frounding-math -DCGAL_NDEBUG -MMD -MQ 'test@exe/main.cpp.o' -MF 'test@exe/main.cpp.o.d' -o 'test@exe/main.cpp.o' -c ../src/main.cpp",
    "file": "../src/main.cpp"
  }
]

Log generated by ncm-clang:

2017-09-30 17:53:14,107 [ERROR @ ncm_clang.py:args_from_cmake:28] 832 - Failed finding args from /home/user/repos/test/build/compile_commands.json for /home/user/repos/test/src/main.cpp                  

If you remove 'ccache' string from "command" in compile_commands.json, everything works fine.

It's quite unconvenient to get no c++11 support when editing a standalone cpp file without specifically telling clang to turn it on (for example, no emplace_back in std::vector's completion candidates). I think it may be better to add a default compiler option to feed compilers, just like what we do in ale:

let g:ale_cpp_clang_options = '-std=c++14 -Wall -Wextra'

My setup:
vim 8.0.1415
roxma/nvim-completion-manager@e724a44
roxma/vim-hug-neovim-rpc@6009384
2cd08c1