IntelliJ plugin

[Prince781]

This is a little far-out, but it would be really nice to have, in addition to VSCode, Vim, and GNOME Builder.

[Prince781]

It looks like we can ask users to install this LSP plugin, which takes care of 3/4ths of our problem:

• https://github.com/gtache/intellij-lsp

However, IntelliJ doesn't have a Vala syntax plugin yet.

[SolarLiner]

Having a slight experience with IntelliJ, the best course of action isn't to rely on a Language Server to provide intelligence; rather the plugin SDK uses its own AST to power many features of the IDE, which means having to write a parser as part of the plugin anyway (the syntax highlighter also uses the lexer and AST which easily enables semantic highlighting).

[gavr123456789]

@SolarLiner Is it still possible to use LibVala with this approach? Can such a plugin be written in a language other than Java/Kotlin?

[SolarLiner]

Ultimately, the plug-in will be called by the IDE, and so needs to run in the same runtime environment. This means we're limited to languages that compile to the JVM only. And unless we can compile libvala to the JVM we need other ways to get libvala, maybe with bindings or, at worst, by porting the code to Java (which shouldn't be too hard considering Vala and Java are solar both in names and in syntax).

[gavr123456789]

@SolarLiner the second variant already implemented by larma.
https://twitter.com/gavr123456789/status/1249770093724274688

He writes the plugin from scratch(judging by the decompilation its on Kotlin), without using LibVala. This entails a lot of problems. For example, you need to implement error analysis, invent the vala syntax parser from scratch, and maintain it if new syntax rules appear in vala. (For example, 0.50 will have an operator.? and the new with keyword).

IntelliJ has an internal index for the code. The parser produces an AST which is then converted into a PSI (program structure interface) which is converted into a Stub (which is structured symbol information). The stub can be serialized and is then put in the index under certain names. I have one index for the full name and one index for the namespace an element is in. Indices use typical database techniques for fast access (hash, search trees). Autocomplete after a dot happens by looking up the type and its super types in the index (by full name) and then listing all the members it has (using the stub). Autocomplete without prefix does the same using the current "this"-type and also uses the namespace index with all namespaces referenced in using, though the current type name and of course "GLib" as well as "" (the empty namespace). All of this happens only on the stub, so no access to the actual files is needed, it all works from an optimized local index database As long as autocomplete/highlighting does not rely on PSI (which requires AST) but can work solely with Stub, it's blazingly fast, after all it's just an optimized database containing exactly the required data

[SolarLiner]

For example, you need to implement error analysis, invent the vala syntax parser from scratch, and maintain it if new syntax rules appear in vala. (For example, 0.50 will have an operator.? and the new with keyword).

This is what happens in basically every IDE though; for example the Rust plug-in for IntelliJ uses its own parser and macro expansion engine, separate from any Rust code.

Furthermore, parsers for interactive tools need to be optimized differently than parsers for compilers; the former need to be incremental and able to recover from errors, while the latter need to generate an AST as fast as possible and can fail on the first error.

I'm glad there's already work on a plug-in for IntelliJ though - Vala is definitely getting popular enough for those projects to bloom, which will in turn attract more people to the language!

[gavr123456789]

By this I meant that it is absolutely not worth doing the same thing that Larma has already done. I think it is worth considering only the option that uses LibVala here.

[SolarLiner]

Why would we create a second IntelliJ extension though? Do they plan on keeping it closed source?

In which case it might be interesting to see how feasible bindings of libvala to Java might be, and how well it would fit in the context of writing the plug-in.

[Prince781]

@SolarLiner there's no need for a separate IntelliJ extension, except for one that can do syntax highlighting. VLS already works with IntelliJ when the above LSP plugin is installed.

[SolarLiner]

Syntax highlighting needs a parser - so we still need to either write the grammar in the plug-in, or use libvala bindings in Java to achieve this. Either way the plug-in will have its own AST.

And I'm of the opinion that using LSP in such a big IDE might not be the best long-term solution - but that's another topic.

[benwaffle]

And I'm of the opinion that using LSP in such a big IDE might not be the best long-term solution

Can you explain this?

[SolarLiner]

Some of the more advanced features of IDEs, things like code analysis and code generation, can't be done through LSPs, which are just a protocol to make code editors smarter. If you want a feature-complete plugin in IntelliJ (or Visual Studio, or any good IDE), you're going to need your own AST tree, symbol resolver, etc. within the plugin, as this will power those advanced features (many of them being implemented by IntelliJ over the plugin's PSI, which is a standardized AST format).

IntelliJ in particular has gone fully in this direction, expecting you to implement a parser for almost any language feature to work (from syntax highlighting and basic formatting, up to more advanced features like duplicate code recognition and refactoring tools).

That is not to say we can't implement a short-term solution right now - if somebody points me to the Vala grammar I can write a plugin with just syntax highlighting and integration with intellij-lsp as it has a programmatic API to automatically register the language server.

[Prince781]

If you want a feature-complete plugin in IntelliJ (or Visual Studio, or any good IDE), you're going to need your own AST tree, symbol resolver, etc.

You are aware that VLS is basically another implementation of the Vala compiler, right? We're just reusing the code for the compiler to show you information about your project. So we have access to all of these things. The LSP is basically an abstraction on top of these compiler data structures. If what you're saying is that the IntelliJ plugin needs to have these raw data structures available, then we could implement extensions in VLS to pass this raw data to an IntelliJ plugin.