Implementing a general language plugin (Reposting from correct address)
aleixpol at kde.org
Sat Apr 27 00:41:23 BST 2019
On Fri, Apr 26, 2019 at 11:06 PM Jonathan Verner <jonathan at temno.eu> wrote:
> 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 . 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  where the communication between the plugin and the server is based on gRPC () 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'
> 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  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:
> 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.
More information about the KDevelop-devel