Add GVls Symbol Completion Provider plugin

[esodan]

GVls is a Vala Language Server, this plugin is a completion provider, allowing to users to select between a list of releated symbols, like methods or properties.

GVls plugin, parses your files as you open them adding any namespace declared by means of usingdirective, so all symbols for, i.e. GLib namespace, will be available.

Once GLib namespace is loaded, you can know all methods for a string variable you have declared.

Any class you declare as you write or from any already opened file, will be available with its methods and properties.

[danirabbit]

Hey thanks for your pull request! Could you please take a look at the elementary code style guide and update your PR to follow that? Thanks :)

Specifically the most obvious things are that we always use explicit namespacing and 4 space indentation

[danirabbit]

It looks like gvlsui-0.10 isn't packaged in Ubuntu, so this is blocked until we have a package for that. That's why CI is failing

[esodan]

Yes GVls-0.10 and GVlsui-0.10 are not packaged for Ubuntu, but the question is what can I do to make it happens?

[esodan]

Are you agree to merge if I disable it by default? so until a debian package exists it can be presented and used on developers (like me constructing Code from source)

Once a deb package is present, this feature can be enable by default.

[esodan]

Please re-consider un block this merge request, as GVls debian packages are at: https://salsa.debian.org/esodan-guest/gvls and GVls plugin is disable if its dependency is not found

[esodan]

I've created a PPA, for GVls, is it acceptable to modify CI for get packages from it?
https://launchpad.net/~esodan-gmail/+archive/ubuntu/ppa

[esodan]

@danrabbit Could you help here?

[harisvsulaiman]

@esodan @danrabbit any update on this ? i was looking forward to vala support and has started implementing a vs code client for it.

[harisvsulaiman]

@esodan I tried the pull request in code, and it seems to work fine. Can you help me navigate your codebase?

PS: I'm attaching a screengrab for anyone who wants to see what its capable of.

[jo3d3v]

The codebase for gvls is here: https://gitlab.gnome.org/esodan/gvls. It will be nice to have a plugin for vscode.

[esodan]

@harisvsulaiman For sure, how can I help you? @jo3d3v pointed out where GVls's repository is located. Please tell me how I can help you.

[esodan]

@danrabbit is it acceptable to add a Meson subproject to help integrate GVls into Code? This will break the requirement of a DEB package. Also, while Code is a FlatHub installable software is possible to make sure it gets and install GVls as part of the flatpak package.

[tintou]

I don't think that we want to have a subproject but as the plugin is optionally built that would make it. If you can fix some codestyle issues too that would be ready to go (newline after })

[cassidyjames]

Still failing lint, see inline suggestions which should resolve it.

[esodan]

@cassidyjames Code needs some love:

1. Add a way to catch when a ProjectFolderItem is added to be used as root for LSP
2. Root LSP should be able to have a LSP Client like interface, to be implemented by plugins like GVls, in order to request information from the server. GVls provides a Client interface, usable, just requires Code to add GVls as a hard dependency no a plug-in
3. Root LSP PrejectFolderItem should have its own LSP Client instance and its own server subprocess

Currently GVls server is attached to a source view, but that is not a good solution, because the server should be attached to a ProjectFolderItem instead, also the Client.

I whould like to know what is the way to proceed in order to continue adding more commits to this MR.

[esodan]

Currently GVls has a new ProjectManager and a BuildSystemMeson objects to generate configuration for LSP. They can be integrated into Code and make GVls a hard dependency. I can start the integration if you accept that.

Comments?

[esodan]

Last commit has fixed issues on initialization using new events on Code's MainWindow, even better IT WORKS FOR COMPLETION!!!!

@jeremypw please test it!!!

[esodan]

@jeremypw I have less time in the following weeks, so please checkout resent commits at gvls-19 branch so you will find new methods to create and maintain a cache of completion items, per project, and associated to Gtk.SourceView objects. This cache will speed up completions.

On Code side is required to know if you will start a complete cache for all symbols in the document, that will take time and resources.

On GVls side GVlsui.SourceViewInitialize should be updated to use this new API in order to create the cache any time a completion request is performed. Look at GVlsui.ProjectManager.completion_items_at(), this method can used to start the completion instead to use GVlsui.CompletionProvider.request_completion () and used inside populate() method implemented by GVlsui.CompletionProvider, because completion_items_at()` find the context at position, check if there is a cache for it, and request completion to the server if no cache is found (also cache the result for future population operations).

Above changes should be on GVls as they will be transparent translated to Code's plugin.

[esodan]

Lets see GVls in action:

Limitations on Gtk.SourceView 4 for completion and may be because Code needs more async operations, don't know, completions doesn't work at first, because response time is long in Code, but in GVls Unit Test are faster.

Once a symbol has been cached response is fast, that is what you see in the GIF. The more symbol's name are cached the more faster response you'll see while coding.

[chances]

Regarding #220, I am working to implement a generic interface for the Language Server Protocol that I think this PR could benefit from with regard to decoupling this implementation from GVls.

For example, https://github.com/Prince781/vala-language-server implements more of the protocol's interface, so I would prefer to configure that server for Vala completions. Regardless, the goal of my protocol project is that it should help make things relatively non-trivial to choose your own LSP server for whichever language you're editing in Code, GNOME Builder, etc.

Perhaps we could model generic interfaces to LSP clients as a set of providers for specific LSP features, such as VS Code's Programmatic Language Features?

[esodan]

Regarding #220, I am working to implement a generic interface for the Language Server Protocol that I think this PR could benefit from with regard to decoupling this implementation from GVls.

For example, https://github.com/Prince781/vala-language-server implents more of the protocol interface, so I would prefer to configure that server for Vala completions. Regardless, the goal of my protocol project is that it should help make things relatively non-trivial to choose your own LSP server for whichever language you're editing in Code, GNOME Builder, etc.

Perhaps we could model generic interfaces to LSP clients as a set of providers for specific LSP features, such as VS Code's Programmatic Language Features?

If you want to use Vala Language Server do it. This plugin can be improved by adding preferences dialog to set the server you want and add GLib.Settings to use your preferences, just change GVlsui.ProjectManager.manager.server_path to ANY SERVER YOU WANT, not just Vala based.

[esodan]

Regarding #220, I am working to implement a generic interface for the Language Server Protocol that I think this PR could benefit from with regard to decoupling this implementation from GVls.

For example, https://github.com/Prince781/vala-language-server implents more of the protocol interface, so I would prefer to configure that server for Vala completions. Regardless, the goal of my protocol project is that it should help make things relatively non-trivial to choose your own LSP server for whichever language you're editing in Code, GNOME Builder, etc.

Perhaps we could model generic interfaces to LSP clients as a set of providers for specific LSP features, such as VS Code's Programmatic Language Features?

Just remember that Vala Language Server can't be compiled on elementaryOS 6 or older, so is unusable for this plugin

But that doesn't mean you can't use other servers, just a preference dialog setting the path to it is enough or make sure to select it based on file's type. A Python or JS LSP server could be useful for Code.

[jeremypw]

I just compiled https://github.com/Prince781/vala-language-server.git on elementary 6 daily OK.

jeremy@elementary-os:~/Elementary/vala-language-server$ build
The Meson build system
Version: 0.53.2
Source dir: /home/jeremy/Elementary/vala-language-server
Build dir: /home/jeremy/Elementary/vala-language-server/build
Build type: native build
Project name: vala-language-server
Project version: 0.48.2
C compiler for the host machine: cc (gcc 9.3.0 "cc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0")
C linker for the host machine: cc ld.bfd 2.34
Vala compiler for the host machine: valac (valac 0.48.18)
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Run-time dependency libvala-0.48 found: YES 0.48.18
Run-time dependency gobject-2.0 found: YES 2.64.6
Run-time dependency jsonrpc-glib-1.0 found: YES 3.33.3
Run-time dependency glib-2.0 found: YES 2.64.6
Run-time dependency gio-2.0 found: YES 2.64.6
Run-time dependency gee-0.8 found: YES 0.20.4
Run-time dependency json-glib-1.0 found: YES 1.4.4
Library posix found: YES
Configuring config.vala using configuration
Run-time dependency gio-unix-2.0 found: YES 2.64.6
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Did not find CMake 'cmake'
Found CMake: NO
Build-time dependency scdoc found: NO (tried pkgconfig and cmake)
Program sh found: YES (/usr/bin/sh)
Program sed found: YES (/usr/bin/sed)
Program gnome-builder found: NO
plugins/gnome-builder/meson.build:14: WARNING: Assuming version 3.38 for GNOME Builder plugin ABI
Configuring vala_langserv.plugin using configuration
Build targets in project: 2

Found ninja-1.10.0 at /usr/bin/ninja
[36/36] Linking target src/vala-language-server.

The only issue is that Gnome Builder in the repo is version 3.36 but presumably it is not essential as I do not have it installed.

[chances]

What of my suggestion to model generic interfaces to LSP clients as a set of providers for specific LSP features, such as VS Code's Programmatic Language Features?

[esodan]

What of my suggestion to model generic interfaces to LSP clients as a set of providers for specific LSP features, such as VS Code's Programmatic Language Features?

GVls Is already what you want to accomplish.

[esodan]

Still failing lint, see inline suggestions which should resolve it.

This has been solved in latest commits.

[chances]

What of my suggestion to model generic interfaces to LSP clients as a set of providers for specific LSP features, such as VS Code's Programmatic Language Features?

GVls Is already what you want to accomplish.

@esodan I think you're misunderstanding me.

I'm proposing a generic interface to expose LSP clients as plugins akin to how VS Code integrates language server extensions, likely via changes to the Scratch.Services.Interface plugin interface.

[esodan]

What of my suggestion to model generic interfaces to LSP clients as a set of providers for specific LSP features, such as VS Code's Programmatic Language Features?

GVls Is already what you want to accomplish.

@esodan I think you're misunderstanding me.

I'm proposing a generic interface to expose LSP clients as plugins akin to how VS Code integrates language server extensions, likely via changes to the Scratch.Services.Interface plugin interface.

I think I understood correctly.

GVls is not just a Vala Language Server. It provides an independent JSON/GObject library framework and an indepent library to create LSP clients and servers; all of them without depending on Vala. GVls provides independent LSP Client as a library and Server as a demon for Vala language, so it could be used with any other Language Server or Client; the server depends on Vala.

With the generic library's API is possible to create a Client that uses Code internals to use the data response from any LSP server out there for any language just adding the required plugin.

[jeremypw]

With the generic library's API is possible to create a Client that uses Code internals to use the data response from any LSP server out there for any language just adding the required plugin.

You are presumably correct, but nevertheless this PR introduces multiple dependencies on fairly large and complex libraries which would presumably have to included with the Flatpak? Forgive me if I am talking nonsense. Is it possible to communicate with a language server from with a sandbox without including all the server's code in the Flatpak?

[esodan]

With the generic library's API is possible to create a Client that uses Code internals to use the data response from any LSP server out there for any language just adding the required plugin.

You are presumably correct, but nevertheless this PR introduces multiple dependencies on fairly large and complex libraries which would presumably have to included with the Flatpak? Forgive me if I am talking nonsense. Is it possible to communicate with a language server from with a sandbox without including all the server's code in the Flatpak?

GNOME Builder Flatpak version includes all server's code compiles and that makes easy to call a subprocess to communicate with, that is the case of GVls and its dependencies.

Flatpak manifest permissions doesn't tell anything about permissions on access executables that can be called as a subprocess (the standard way to connect to LSP servers). See the Builder's Flatpak allows to install an extension org.freedesktop.Sdk.Extension.rust-stable so rust-analyzer (the rust LSP server) can be accesses and called as a subprocess of Builder Flatpak version.

When GVls can gain more widespread use, may a Freedesktop SDK extension can be created to provide Builder's similar approach. In the middle include GVls's source code and its dependencies is the way to go I think.

GVls has a TCP/IP server Flatpak version and so any other LSP providing such kind of connection, while the Flatpak provides access to the network, just installing in the system by Flatpak or any other way is enough to communicate Code's Flatpak version to. This PR can be modified easy to switch from a subprocess to TCP/IP connection.

[jeremypw]

I think this can be closed now. Maybe a better approach would be to work on a Flatpak branch that works out of the box? Code is intended to be installed as Flatpak anyway (master does already mostly work as a Flatpak).