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

--nextPart1981077.quHd1r9qze
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Milian Wolff <[email protected]>
To: [email protected]
Cc: Sven Brauch <mail-ITmcY+a7/[email protected]>
Subject: Re: KDevelop problems suitable for a Ph.D. thesis
Date: Fri, 06 Sep 2024 14:44:02 +0200
Message-ID: <3932960.oMgaU72ii9@milian-workstation>
In-Reply-To: <4be9b6a3-8783-4e6c-9f0c-aefadf3da72a-ITmcY+a7/[email protected]>
MIME-Version: 1.0

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 ;)

:)

-- 
Milian Wolff
[email protected]
http://milianw.de
--nextPart1981077.quHd1r9qze
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEezawi1aUvUGg3A1+8zYW/HGdOX8FAmba+RIACgkQ8zYW/HGd
OX8dnRAAh/v6BpwlT5EaQZv+OknuK5ud1dhGLCtEGMuG/LAlh9uPYw6T6Fypn/vK
A8ZNqlQo5Ya0/DeNkOfKW5f5+7nW90HjFosmMlYp386kxeYeOoIbIq3JRzMTWLQY
KhT4PBGCXqPkssS4HIBQ+pgfPcogEZ12pCJA4q2GugSs1g+99UiZb2iDoOgMpmCy
74ZnK1/8MH87eUVzaIuzQwdx10591CsFN0JURQEf+1S8hvJp+nhA6PcHCdHaps5+
aYkI4B1QbUKKerMHOoIUTJ2JaraP/CkvptQ5+NPAszR4LtymkjMndh6NizQFHgm6
kK+aAMmNmpFVqSFUuojHonOotLNat+p0UvRyFW8QcbqxkdgLHVXVjnrcmQixo6HN
zIopDP3nWA6F1mIXIgK1TNFEirkFQn+YatbNCNQZIybPf9w31/PN8q+pzgtdgS+T
LbUI79DloMXQNTuDDbxiDJrA14rnYQ4RZynIPG2y5Laoa2EiWHyR5HX5JwbEP7t/
Q69yiz0hKGglaWjqFEdPGxqhr59DpWXj0Q3o7YnWeZPUa1NMAyzb1Tc7wd4T7a34
Rm9/aRw/MNBpwAHoi93jDPPiWS0KCGQuSnBKYEiuvWVYztxuGfQXZfZBc+vWxVpS
aDXwNxeJd4/L78+PEdEqgvtmtiXivY7IWAEc2qBhxFURo4ZS/co=
=Ci+m
-----END PGP SIGNATURE-----

--nextPart1981077.quHd1r9qze--