KDevelop problems suitable for a Ph.D. thesis

[Igor Kushnir]

On 2024-09-06 3:44 PM, Milian Wolff wrote:
> On Donnerstag, 5. September 2024 21:11:16 MESZ Sven Brauch wrote:
>> Hi,
>>
>> On 03.09.24 13:18, Igor Kushnir wrote:
>>
>>> I have considered integrating Language Server Protocol (LSP).
>>
>>
>> I also think this won't work, LSP doesn't really seem designed to fully
>> back an IDE like KDevelop. Its data is in the server, and you query it
>> over the protocol using high-level queries, which isn't really
>> compatible with how almost everything in KDevelop is built.
>>
>> I wonder if it is worth exploring whether a different protocol could be
>> created, closer to what the KDevelop data model works like. Essentially,
>> move KDevelop's language plugins out-of-process (which might be a good
>> idea anyways) and provide the data needed to fill the duchain over some
>> protocol. Querying would remain in KDevelop itself. Compared to LSP,
>> this approach would only outsource the "dumb" part of analysis to an
>> external tool, and more of the "intelligence" would remain in the IDEs
>> themselves, hopefully simplifying improvements.
> 
> My personal hunch is that we should be able to add a level of abstraction
> between the needs of our various high level tasks and the low level
> implementation in terms of the DUChain.
> 
> A language plugin would then get the API to do various things, such as code
> completion, document outline, quick open, code browsing/references, ...
> 
> Our existing plugins would implement that through shared code that uses the
> DUChain directly.
> 
> Then we could implement the new API also in terms of the LSP (or anything
> else, really) to finally get better support for more languages.
> 
> Once that works, and the DUChain access is nicely encapsulated within
> individual language plugins, we could also try to move them out-of-process to
> better guard against crashes.
> 
> While at it, we could try to make the code base more async friendly e.g. via
> QtCoro and C++20 and discuss the implications thereof on our large code base.
> 
>> Certainly not a weekend project, but you didn't ask for one as I
>> understood ;)
> 
> :)
> 

I just read two articles about the LSP: 
https://matklad.github.io/2022/04/25/why-lsp.html and 
https://matklad.github.io/2023/10/12/lsp-could-have-been-better.html . My 
conclusion is that on the one hand the LSP is without alternatives in terms of 
the number of languages that can be supported with little effort; and on the 
other hand, major drawbacks of the LSP compound the issue of poor compatibility 
with existing KDevelop language support architecture. It is then tempting to 
wait till a better replacement protocol arrives instead of integrating the LSP 
now. The problem is that there is no telling when that might happen.

By refusing to adopt the LSP standard and investing major effort in redesigning 
KDevelop's custom language support framework instead, we risk being left behind 
in not so distant future. Therefore, I heartily agree with Milian that we should 
make DUChain optional for KDevelop language plugins. What is the chance that an 
alternative to LSP arrives in the nearest future *and* is well compatible with 
the DUChain architecture? Almost all KDevelop language plugins are practically 
unsupported, and most do not even compile against the latest KDevPlatform 
version. So we can't realistically expect people to write many good 
KDevelop-specific DUChain-based language plugins and support them long-term.

I think I can work on the interesting and important problem well defined by 
Milian. Absolutely essential is splitting the problem into incremental tasks, 
each useful and at least somewhat scientifically interesting on its own. So that 
each task can be completed in a few months, merged without waiting for the next 
step, and a paper be written about it. Well, at least the first couple of tasks 
should fit into a few months each.

Perhaps the first task can be: devise a good API for a single high-level 
KDevelop feature (preferably a simple one). Implement it on the IDE side. Then 
either implement a small API adapter library and use it in existing 
DUChain-based language plugins, or implement an opt-out API adapter layer inside 
KDevPlatform to avoid the effort of adjusting and testing all "supported" plugins.

The second task can be: implement an LSP-based language plugin against the API 
implemented in the first task. This would test the API and confirm that it is 
implementable without DUChain. The intrinsic value of the single-feature plugin 
implemented in this step would be low of course. But it could then be extended 
to support each subsequently implemented API for other high-level KDevelop 
features. Not sure the implementation of the first task should be merged into 
master before completing this second task. We'll see how long it takes.

I hope we can come to a consensus about the overall plan, devise and agree on a 
good first task in the near future. But there is no point to spend time on this 
before I win the postgraduate competition. I expect to know the result by 
October. And again, I'd better concentrate on preparing to exams during the next 
week or two. Just set my status to Busy on KDE's GitLab instance :)

Cheers,
Igor