LSP in KDevelop

[christoph at cullmann.io]

Hi,

On 2024-09-14 11:41, Jonathan Verner wrote:
> Hi, this is really cool.
> 
> I have a local build where I just removed the blacklisting of kate
> plugins and the LSP plugin seems to mostly work
> (except for kdevelop crashing on exit ;-)), so I think this is a very
> viable approach. Also, I wonder
> if it would make sense to revisit the list of blacklisted plugins
> (e.g. the git-blame plugin and the
> plugin to make url's clickable work fine and are very nice)...

I second that, I would not load most Kate stuff per default,
even Kate doesn't do that, but I fail to see why one needs to blacklist 
stuff.

I would like to have more collaboration on the plugins, too, so far the 
'shared'
infrastructure I did build unfortunately didn't lead to that.

Greetings
Christoph

> 
> Anyway, thanks for working on this!!
> 
> Jonathan
> 
> On Wed, Sep 11, 2024 at 10:08 PM Sven Brauch <mail at svenbrauch.de> 
> wrote:
>> 
>> Hi,
>> 
>> (CCing kwrite-devel, see last paragraph why)
>> 
>> at Akademy, I had a look at integrating Kate's LSP plugin [1].
>> 
>> I think it's a good idea to do this because it gives us kinda-good
>> support for lots of languages which people have come to expect these
>> days, and especially provides a plausible path for phasing out our 
>> qmljs
>> plugin -- I have no idea how that would be fixable to work with 
>> current
>> qml otherwise, given our manpower constraints.
>> 
>> In the MR, I for now only did the absolutely-required part of the
>> integration, i.e.
>> 
>>   - fixed support for Kate's toolview API
>>   - added support for showing config pages from kate plugins in our
>> config dialog
>>   - added and invoked API to disable the C++, Python, and PHP LSP 
>> servers
>>   - integrated the LSP meta diagnostics ("failed to start server" etc)
>> into a messages toolview of ours so people can see why things don't 
>> work
>> 
>> It works kinda fine, what is lacking is that it has its own outline 
>> and
>> diagnostics views, and doesn't integrate into our quickopen. 
>> Especially
>> the latter isn't so nice.
>> 
>> I'll have a look at how I can integrate this better. Since the data is
>> structurally not super complicated, I'm considering not exporting a 
>> C++
>> interface (with BIC problems and all) but instead just adding a few
>> signals and Q_INVOKABLES to the LSP plugin object which return variant
>> maps and item models. I hope this is sufficient and it should be 
>> doable
>> with minimum impact on the kate side.
>> 
>> If you have major doubts about all of this, let me know.
>> 
>> All the best,
>> Sven
>> 
>> ___________
>> [1] https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/669