kate lsp client plugin

[Mark Nauwelaerts]

On 01/07/19 20:57, Christoph Cullmann wrote:
> On 2019-07-01 19:57, Christoph Cullmann wrote:
>> Hi,
>>
>>>> I pushed some additional commits in the meantime to support some more
>>>> LSP features.  Some other tweaks in server management are pending, and
>>>> will next be looking into making some (server) configuration not so
>>>> hard-coded as it is now.  That will probably (at least for now) refer
>>>> to some (external) JSON, since the protocol ('initialize' settings)
>>>> are JSON anyway, and so are kate's project settings (which might later
>>>> provide additional/override settings), or compile_commands.json (so
>>>> plenty of that around already) ...
>>>
>>> Having the stuff configurable would already by great, JSON seems like a natural
>>> choice given it's use everywhere in LSP.
>>
>> I played a bit more with the plugin.
>>
>> The Python stuff seems to work fine for the normal things out of the box, nice!
>>
>> For C++, I think one issue is, that the baseDir of the project is used,
>> even for e.g. the CMake generated .kateproject files, were the
>> compilation database
>> will be in the directory of the .kateproject file but not the base dir.
>
> ;=) Here a patch to choose the right dir + a hack to make clangd use it for 
> compile database.
>
> With this I get a fully working completion and co. for e.g. kate.git's CMake 
> generated project.
>
> I assume that initializationOptions JSON stuff is what you talked about to 
> make configurable, or?
>
> Greetings
> Christoph
>
I was indeed referring to initializationOptions, among others. Although it's 
possible, I have to admit I had not considered it for clangd 
'compilationDatabasePath' since I followed the instructions on 
https://clang.llvm.org/extra/clangd/Installation.html and used a symlink (in 
project/source root) to make clangd find the compilation db in the build 
directory ;-)  That way, I can also use 1 instance for several (small 
cross-referencing) projects with separate compilation db's.  And this one 
instance will find them all by looking up into parent dirs.  And if it finds 
one, then it is happy and things work well.  If not, it (indeed) tends to 
degrade a lot quickly.

Other experiments and code investigation show that the "rootUri" is not 
important for clangd (or python server) and almost not used.  So it does not 
matter all that much to what that is set exactly either.

All in all, that makes the projectBase (or variant thereof) less important and 
if possible, I would try to steer configuration to promote fewer (server) 
instances, but to still allow separate ones (e.g. per project) with projectMap 
override configuration. However, all that would then be (static) config file 
based, so it's not (yet) clear how to fit in such clever dynamic (projectMap 
lookup-based) server-specific hack ;-)

But I'll first try to allow for configuring the server (command line) without 
needing to recompile ;-)

Regards,
Mark