Re: KDevelop problems suitable for a Ph.D. thesis

Hi everyone,

On 2024-09-06 4:51 PM, Igor Kushnir wrote:
> 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 :)

The postgraduate competition was particularly tough this year, and I lost it. 
Perhaps I'll try again next year. This year, there is a possibility I'll solve 
some KDevelop problem(s) and write a scientific paper or two about it, but I 
don't expect to have much time for this.

Whether I or someone else will eventually work on it, below is some more info on 
the language plugin refactoring topic.

Sven Brauch has replied to me personally by mistake, so I am quoting here:
On 2024-09-08 10:30 AM, Sven Brauch wrote:
 > Hi,
 >
 > On 06.09.24 14:51, Igor Kushnir wrote:
 >> 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.
 >
 > to be fair, most of them didn't ever work, e.g the Java plugin. The only one
 > which kinda worked and has fallen into serious disrepair is qmljs, and maybe
 > Ruby but that has never seen an official release. But I digress.
 >
 > Milian's idea sounds good to me, it's a similar vision to what I was trying to
 > describe but more specific.
 >
 > If trying to do that, I would suggest starting with code completion. It's a very
 > valuable feature, and I think not many changes would be needed to add such an
 > interface (it already exists in similar shape for the most part). The navigation
 > widget could also be a candidate, a similar interface exists and is basically
 > 1:1 adopted (through inheritance) by most languages.
 >
 > Highlighting is going to be harder to do I guess.
 >
 > Greetings,
 > Sven

Independently, I had also considered starting with the code completion feature, 
which already has at least the KTextEditor interface. Could be a good start.

I have briefly analyzed Qt Creator's implementation of language support. Qt 
Creator had traditionally supported C++ language features heuristically, 
similarly to how KDevelop did it before the libclang plugin. Then a clangd (LSP) 
plugin arrived. But Qt Creator still allows to disable the clangd plugin to save 
memory. So Qt Creator supports two very different C++ solutions - just what we 
want in KDevelop for C++ and other languages (DUChain and LSP).

Qt Creator's language support appears to be more heterogeneous/specialized. For 
example, in 
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/qmljseditor/qmljseditor.h 
the class QmlJSEditorWidget inherits TextEditor::TextEditorWidget and 
reimplements, among others, text editing features. The TextEditorWidget class is 
inherited by many (all?) other language-specific classes as well. I guess 
KTextEditor and KSyntaxHighlighting take care of many of these things for 
KDevelop, but perhaps they don't offer so much flexibility as Qt Creator's approach.

The ModelManagerSupport interface is inherited by two C++ support classes 
BuiltinModelManagerSupport and ClangModelManagerSupport (clangd): 
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/cppeditor/cppbuiltinmodelmanagersupport.h 
. For some reason, Qt Creator uses std::function callbacks rather than 
signals&slots to let asynchronous implementations reply in their own time.

I had hoped we could reuse Qt Creator's interfaces and even LSP plugin 
implementations. But since Qt Creator does not cleanly separate text editing and 
language support interfaces, I am more inclined to use KTextEditor's LSP plugin 
as a base, borrow only some interface and implementation ideas from Qt Creator. 
On the upside, this would bypass possible concerns with Qt Creator's GPL-3.0 
license.

Cheers,
Igor