Implementing a general language plugin (Reposting from correct address)

[Aleix Pol]

On Fri, Apr 26, 2019 at 11:06 PM Jonathan Verner <jonathan at temno.eu> wrote:
>
> Hi,
>
> I got addicted to semantic coloring (the thing where kdevelop colors variables and their uses in separate colors) and now using other IDEs is a pain :-) However, I was recently doing some frontend JavaScript work and found out that kdevelop has trouble understanding modern JavaScript so I had to reluctantly resort to VSCode [4].  Also, I will probably be forced to write quite a lot of code in C# which, as far as I know, has no support in kdevelop.  So I decided to try to sit down and write a language plugin. Now there is no way that I would be able to write and *maintain* a decent parser for either of the languages so the only option left to me was to use the tools the languages already have.
>
> However, the problem here is, that kdevelop needs language plugins to be written in C++. At first I thought I would look into writing a plugin which would be able to utilize the "Language Server Protocol" used by VSCode [1]. However, it seems that the LSP is too limited to support the cool stuff kdevelop does (i.e. semantic coloring). So my next plan is to implement something "along the lines of" LSP, but for kdevelop.  The main idea is, that the plugin would connect to separate servers for each supported language. The servers would then provide it with a DUChain which it would feed to KDevelop. I.e. the workflow would look roughly like this
>
>   1. User updates a file
>   2. KDevelops calls my language plugin to start a Parse Job
>   3. The plugin connects to an appropriate language server and asks it to produce a DU Chain for the updated file
>   4. Upon receiving the DUChain it updates the DUChain  KDevelop has for the file
>
> I am currently experimenting with a quick and dirty implementation [5] where the communication between the plugin and the server is based on gRPC ([2]) and ProtocolBuffers. I have a few questions:

I think that if you manage to pull this off, this could be really cool
:). It will be far from easy too ;).
We were tempted to start working on LSP in the past but our conclusion
was too that it didn't map well enough to abstractions and our users'
standards.

>   1. do you think this approach is workable (so far I didn't run into any obvious roadblocks, but I am new to the codebase)

I suggest you look carefully at which level of the abstraction you
want to hook your system to. If you find the right place it will
become much easier. Other people in this mailing list are far more
qualified than I am to comment on it, so I'll let them do it first.

>   2. my knowledge of the DU Chain comes just from reading the available docs here [3] and the source code of the go plugin; however, I am sometimes quite confused and I wonder, if there is a tool which would output the DU Chain for a given file in a "human readable" format --- that would help me very much, I think

There's DUChainDumper::dump which prints to the command line if you
want to do it from within KDevelop.
You can find as well the duchainify tool in the repository which can
be useful to test the parser, see in your build directory:
kdevplatform/util/duchainify/duchainify

>   3. I haven't been able to figure out how kdevelop determines, what plugin should run the parse job for a given file; so far it seems that I need to provide a mime-type in the plugin json file and then kdevelop calls my plugin if the mimetype matches; unfortunately, this will obviously not work if my plugin wants to support different languages, ideally configured at runtime based on the available language servers... Is there a way around this?

Sure, we can modify the code so that it's done any way we want.

Good luck!
Aleix