Some questions regarding LSP integration

[Alexander Neundorf]

Hi,

On Donnerstag, 10. Februar 2022 22:59:32 CET you wrote:
> Hi,
> 
> > On Donnerstag, 10. Februar 2022 06:55:19 CET Waqar Ahmed wrote:
> >> Hi,
> >> 
> >> Yes, that is more or less what clangd does.
> >> 
> >> > (so this will often fail)
> >> 
> >> Yes, if there is no compile_commands.json found. And there can be
> >> multiple build dirs with multiple different compile_commands.json
> >> lying around (Think about people working on porting kde software to
> >> Qt6, they may have 2 build dirs one for Qt5 and one for Qt6, both
> >> having different compile_commands).
> > 
> > yes, sure, or simply having a DEBUG and a RELEASE build, or any other
> > differing build options in different build trees, e.g. using a
> > system-provided
> > library vs. the library coming from some 3rdparty/ directory.
> > 
> > Modifying the contents of ${CMAKE_SOURCE_DIR} in some way feels wrong,
> > it should be considered read-only for build tools (so different build
> > trees don't interfer with each other).
> > 
> > But if that's the only way how clangd works, then that's how it is.
> 
> It is at least the most easy way to get that tooling working properly.
> Even more if you want to e.g. use the clang-format stuff just in some
> random shell.

I started looking at the code, I'll have a look what it would take to have one 
LSPClientServer per open cmake-based project (from the project plugin), and 
actually set the directory via clangd command line option.
Then each build tree would, without any copying or symlinking, would get the 
correct build flags etc.
But it will take some time until I get to do it.

...
> > One more question: in the Project settings, there is a "Project index".
> > Is
> > this an index coming from LSP, or what kind of index is it ?
> 
> No, the project index is ATM ctags based.

Does this depend on the ctags plugin being enabled ?

Alex