Open matzipan opened 7 years ago
https://github.com/benwaffle/vala-language-server
Though I am a strong user of python, (where 2 LSP exist!) it is better to have at least one vala LSP Server. :P (Or we can code an add-on just for vala)
I second that. Language Server protocol seems to have gained traction: aside of the ones mentioned above, there a few for Ruby, there is at least one for Go, and it's the official editor integration for Rust. That's in addition to C++, HTML and CSS that were created along with Language Server protocol itself.
A list of language server implementations for languages can be found here: https://microsoft.github.io/language-server-protocol/implementors/servers/
I don’t know if this is solvable by elementary, since it uses GtkSourceView, which has its own language support system
Actually, GNOME builder uses LSP (according to Wikipedia) https://en.m.wikipedia.org/wiki/GNOME_Builder So it is possible!
+1, Intellisense along with all the IDE features likes jump to definitions etc can be added if the editor implemented the Language Server Protocol, created by Microsoft to standardize editors' language functionalities. IDEs implementing the LSP can immediately use exiting language servers. For instance Sublime, Atom, VSCode, even Vim have the protocol implemented it.
The specs are defined here.
Benefits:
I'd like to add that juicpp claims to support language servers if available. It uses GtkSourceView too.
Actually, GNOME builder uses LSP (according to Wikipedia) https://en.m.wikipedia.org/wiki/GNOME_Builder So it is possible!
AFAIK, Builder doesn't use LSP directly; however the Rust integration plugin is basically an interface to the rust language server.
I don't see why using GtkSourceView would prevent implementing a Language Server client - GtkSourceView only takes care of syntax highlighting, and as shown in GNOME Builder and juicpp
, both error squiggles and code completion can be implemented. It's only a matter of sending JSON-RPC to the server (through stdin/stdout, sockets, IPC, etc.; the protocol is transport-agnostic), getting back data, process it, and show it to the user.
Is this dead? :(
I was about to file an issue to use LSP and found this. Some of the benefits of using VSCode over Code is the code completion. I would love to use Code full time if it could support LSP since most languages do have their implementation for it. Would this be a feature Code would entertain?
If the mission of Code is to not compete with or replace other editors I understand that since LSP support might be viewed as more of an IDE feature than a simple text editor with basic syntax highlighting. If the mission of Code is to stay as a simple text editor it makes sense not to take on VSCode-like features.
Speaking of LSP, has anybody had any luck with using vala-language-server from https://github.com/benwaffle/vala-language-server
@elementary I'd like to take some ownership of this issue in tandem with my LSP protocol work. Is there a formal process for issue assignment? Or shall I just open a PR?
@chances Note PR #599 is making some progress. How does that fit with what you had in mind? There is no formal process for issue assignment you can just open a PR. Obviously its best to make sure what you want to do is in line with the UX team's view before doing too much work.
@chances Lets work together. GVls already provides a Generic LSP Client, support lot of methods and any remaining are easy to implement. LSP Client can connect to virtually any LSP out there including Vala Language Server.
GVls provides a generic interface for GLib.Object
to/from GLib.Variant
, so is easy to create a class and make it easy to convert a class to JSON, just implement GVls.VariantObject
and mark what properties, for the names that will be present on JSON, you want to use.
Also GVls has support for ANY OTHER server, including #599 can use VLS too just configure it to do so using GVlsui.ProjectManager.manager.server_path
.
GVls is written in Vala.
Now that GVls has split out Vala LSP Client and Server, is possible to integrate in Code an infrastructure to allow developers to create LSP clients to connect to any LSP servers out there with minimum dependencies.
First plugin should be a Vala LSP Client, that could use any Vala LSP Server out there, may it can detect if GVls or VLS are installed and make them available to the user to choose from, using GVls generic interfaces for LSP clients.
Code should use GVls interfaces and start projects detecting file's type to lunch a Client plugin supporting it. The plugin should manage the server connection and user settings to the server, like what server the user wants to connect to.
What do you guys think about my project https://github.com/Prince781/lsp-glib which is supposed to provide support for the LSP with a modular API? I've been designing it with editors like elementary Code in mind. Work has been slow as I've been busy with other things, but I'd love to have help from someone in getting LSP support into Code using this library.
I can give a hand in supporting LSP if someone tells me what to do
@aitor-gomila Thanks for the offer! I would say the first thing to do would be to review the state of play for LSP servers available and see what is currently needed to implement a client (probably as a plugin) in Code. We do not have the resources to contribute to the development of servers and we need a fairly stable API to work with. The language server(s) must be easily available, easily installable and well supported. We need to be able to implement a client in a straightforward way without too many extra dependencies. The plugin needs to work well in conjunction with other plugins like word-completion and with good performance. If you look under "Stale Branches" in this project you will see some previous attempts with GVls that at the time I could not get to work properly.
vala-lang/vala-language-server
looks a likely candidate for the server as it is in the apt repository?
@aitor-gomila I'm also the main developer of vala-language-server. I would be willing to mentor you in creating a plugin for Code that uses lsp-glib to talk to VLS and other language server clients. What do you think?
@Prince781 That would be great! Does gtk source view already have some support for autocompletion etc.? Or does it have to be built from the ground up? Because then I don't have a lot of experience. But if it's just LSP then I might be able to do it.
GSV supports showing completion boxes. The suggestions will come from the language server.
https://gnome.pages.gitlab.gnome.org/gtksourceview/gtksourceview5/class.Completion.html
Using Code is very unresponsive to me. Even unrelated stuff to coding like opening a menu. I think this is in part due to the plugin system being in the same thread as the UI, so creating a LSP plugin which is heavy would make Code even slower on poor CPUs like mine (Celeron N4020). Would it be feasable to change how plugins run in the next major version? Or can you think of a fix for this?
Code also shows up in the section of "applications using lots of power" which heavier apps like vscode or chrome don't.
@aitor-gomila Your issue sounds similar to #409. I don't know if Code has improved (or deteriorated) since that issue was filed. Might be worth creating a project to overhaul the plugin system and improve performance.
The minimum specification elementaryos recommends is here https://elementary.io/docs/installation#recommended-system-specifications
Interesting to note an SSD is "required". I use an spinning disk machine (albeit with an i5 processor) with adequate results (apart from slow Flatpak launching). That said, I am in the process of upgrading and SSD seems default these days.
@aitor-gomila Your issue sounds similar to #409. I don't know if Code has improved (or deteriorated) since that issue was filed. Might be worth creating a project to overhaul the plugin system and improve performance.
This reminds me of Music app in 6.0-6.1. Something I learnt while working in VSCode is that extensions, even if badly-written, should never make the core of the editor slower.
Gedit also showed me that a code editor is just a way to open files and edit code and that's all. Then plugins can add a file tree view which you can use to open the files. This is just one example.
lsp-glib has an asynchronous API and language servers are out-of-process, so if we implement the plugin right there shouldn't be any UI slowdown.
still nothing after 7 years... never happening.
elementary is a free product you get to use, developed by people on their own time and resources. Are you making any effort on your own, either programming or financial, to see this feature completed?
We'd all love to see this feature in, but it would take a fair amount of work and everyone in the discussion seems to be busy with other things. If you think you can do it, feel free to implement this and open a PR. Alternatively, you can help out existing efforts mentioned in the thread. Lastly, you can pay someone to work on this feature.
Should be easier to add once #1157 and #1066 are resolved.
The language server protocol aims to fix the editor language support problem. We should use it.