what about clangd?

[René J.V. Bertin]

On Friday August 23 2019 23:45:15 Sven Brauch wrote:
>It's 
>messy, pointless and confuses everyone.

It could indeed be messy if both plugins get to be active at the same time. But both are based on clang so the parsing result should be the same, or the results from the LSP plugin should at least be a subset of the "official" plugin, so with some care to ensure that only the most capable plugin is used most users shouldn't even realise that there are multiple C/C++ parser plugins.

The keywords here are lightweight (as in Christoph's earlier reply) and "most capable". Currently KDevelop's clang parser plugin isn't very capable at all in practice unless you're dealing with CMake or QMake-based projects (the jury is still out on Meson AFAIAC). If you're working with a Makefile-based project (= all autoconf projects) or something completely different (the atom editor or Electron sources for instance) you're SOL, and that has been a recurrent source for questions on the user ML. We can only guess about how many potential users didn't even bother to come ask after test-driving KDevelop and seeing it failed on their projects (just like I did with the CodeBlocks IDE).

There has been some chatter (last year?) about a quick patch that someone made to add support for compile commands databases (compile_commands.json) to the Custom Makefile or Generic project manager plugins. Apparently that improved things a lot but I never heard of it again, but I presume it would already have been mentioned here if something like this had been included in 5.4 .

That's where the lightweight comes in ... from what I can tell KDevelop's approach to parsing is a far from that, apparently opaque enough to scare away potential contributers to start looking into improving matters here, while those who know the code well enough apparently do not care enough to spend the necessary time and effort. I'm not accusing anyone here, I'm guilty myself of not even sitting to try and understand exactly how much time and effort it'd cost me to write a proper implementation (at least I have the excuse of a proven track record of disagreement on what's proper :-/).

About that: at first sight a proper implementation would take the existing compile_commands.json project management code from the cmake plugin and move it to a parent class where it becomes available to other project manager plugins too?


R