Include an LSP client to the script editor

[BenjaminNavarro]

Describe the project you are working on

3D game, but not relevant

Describe the problem or limitation you are having in your project

Currently, the script editor only fully supports GDScript so in order to work with other languages (C# or GDNative based ones) users have to rely on an external editor.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Implementing a client for the LSP protocol would open up easy editing of a wide variety of programming languages, which would be a huge plus, especially for beginners.

Of course the goal would not be to replace full-fledged IDEs but it would bring a level of comfort that should be sufficient for most usages. Together with a better integration of GDNative in the editor (#119) it would bring Godot to a whole new level in terms of language support.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I'm not familiar with the details of the LSP but from what I understood, the editor provides the base functionalities that are shared for all languages and then language support is just a thin layer on top of that. These layers could be included for the officially supported languages and provided by plugins for the other ones.

Also, since Godot provides an LSP server for GDScript, it could be reused internally, which would probably remove some GDScript specific code from the script editor and makes sure that the experience is the same when editing GDScript files from within or outside the engine.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It can't since it touches core functionalities of the script editor.

Is there a reason why this should be core and not an add-on in the asset library?

I don't think the script editor is customizable in that way using an add-on.

[YuriSizov]

users have to rely on an external editor.

Arguably, users pick other languages because they want to use them with familiar tooling. So I'm not sure I see much use in this for us.

As for GDNative, they can already be integrated into the built-in editor. Godot-Python does it.

[Calinou]

Related to #712.

[BenjaminNavarro]

users have to rely on an external editor.

Arguably, users pick other languages because they want to use them with familiar tooling. So I'm not sure I see much use in this for us.

As a C++ dev myself, I'd rather code the small C++ part of my game inside the editor rather than firing up an external tool just for that. Might be a matter of preference.

As for GDNative, they can already be integrated into the built-in editor. Godot-Python does it.

Oh I didn't know that. Does the plugin provides full support in the editor (syntax highlighting, autocompleting, etc) ? It's not clear from the project description. But even in that case, having an integrated LSP client would probably make the writing of such plugins much simpler since there's an LSP server for almost any language now.

EDIT: regarding #712 it would also help because a plugin could provide the interface between the LSP client and omnisharp

[YuriSizov]

Does the plugin provides full support in the editor (syntax highlighting, autocompleting, etc) ?

To my understanding, yes. I've not used it personally to confirm this though. Also important to note that, as far as I know, this is only possible for PluginScript and not NativeScript (those are two ways a language binding can be implemented).

I'm completely against the idea of the LSP support, but we must first evaluate the idea further to understand how much it effort it would take. I am still no convinced it's very useful, but this cannot be offloaded to the pluginland, so there is no easy way out 🙂

As a C++ dev myself, I'd rather code the small C++ part of my game inside the editor rather than firing up an external tool just for that. Might be a matter of preference.

I think an instance of VS Code is always useful to have open on a side. I use it to edit resource metadata directly in the text files and do mass changes to the project, while coding exclusively inside of the Godot editor. They pretty much compliment each other.

[Shadowblitz16]

@pycbouh You have to realize vs code does not work most of the time and the microsoft c++ and c# plugins are garbage.
Things like visual studio are windows only. and things like clion and rider cost money, let alone clion requires cmake ugh.

Also if you have a single screen like me there isn't enough room to open both a ide and the godot editor so you have to manually switch between the windows that are overlapping. Also loading up the ide's take time and memory
Thats lot slower then if the godot editor provided support for its official languages

[YuriSizov]

@Shadowblitz16 That's only your opinion. There are plenty of people using VS Code for C++ development, myself included. And once again, people who prefer to use Godot with C# or one of the GDNative languages are usually not only familiar, but proficient with their developer tools and want to use them. The situation where they would want to code from within Godot is very much artificial.

[Shadowblitz16]

@pycbouh thats not just a opinion but also my experience.
Unity3d doesn't have a official C# editor either but there are add-ons that provide it that are very popular.
https://assetstore.unity.com/packages/tools/visual-scripting/script-inspector-3-3535
So its definitely not just my opinion.
People only use vs code because they don't have a choice
If there was builtin support I guarantee at least 50% or more people would use it

[Duroxxigar]

Having LSP support for something like C# in the editor would be nice, yes, no disagreement there. Neikeq has already stated that they are open to having it included as well. But no one has stepped up to do it and Neikeq is still pretty much the only person maintaining the C# support for Godot. Because .Net already has a rich ecosystem of tools available to the developers, I (and Neikeq) would prefer that he works on the far more important things.

A huge lure of using C# is that it is a statically typed language, the maturity of the language, the experience the developer has with the language, and the mature tooling that developers are familiar with. Pyc is correct in their assertion on why people stick with C#.

As for the evidence you provided, it is hardly a case that proves it is "very popular". It has 236 reviews, so we can only guarantee that 236 people purchased it. Sure, we can multiply that by 10 or 20 to be on the safe side with a generous ratio, so roughly 5,000 people. Hardly something I'd say is "very popular" for something that has the community size of Unity.

And where did you get the 50% ratio? What was your process for determining that?

There are plenty of active users of C# in Godot's Discord that I interact with or observe. And the consensus is pretty much the same. It would be nice, but we don't really care for it because we're comfortable with our current tooling (yes, I do use C# in Godot as well).

[Shadowblitz16]

I thought the 100,000+ was for the asset it wasn't though
but it does say that 2090 users favorited it.
and things are always more popular then they seem

for example...
if you have 100 likes on your youtube video that just guarantees at least 100 people liked it that's definitely not the actual number
I certainly don't like or subscribe to everything I watch on youtube

The 50% was just a guess based on the 100,000+ number,
but if something is easier to access and use most people will use it instead of the external alternative

[Duroxxigar]

Yes - If you reread what I said, you'll see that I brought up that there is most likely more than 236 people who purchased it. But we can only guarantee 236, anything else is speculative. Even 200,000 is a small percentage of Unity's userbase. It crossed 2 million back in 2013.

Making guesses on guarantees of percentages only diminishes your argument ("I guarantee that at least 50% more people") <--- that is a complete guess with a number pulled from the sky.

[Shadowblitz16]

@Duroxxigar 200,000 is a lot of people and what it looks like is 100,000 the number of people supporting the unity asset store.
my guess was based on that number as like I said I thought it was for the asset.

236 is again the reviews, it says 2090 favorites it so that guarantees at its either between 2090 and 236 or above 2090 if you consider not everyone that would use it or has come across it has favorited it

but let me ask your this question..
If vs code is clearly the better option, why do we use godot's built in gdscript editor instead of it?
The answer comes to either...

• its more convenient to use
• its better at integrating with Godot
• it requires less screen space

vs code from what your implying is a better editor otherwise and should be used.

[Duroxxigar]

So - the part that you were looking at, at the top of the page, is a legend. It doesn't mean anything other than guiding what those symbols would mean if you saw them. Even if all 2090 people purchased the asset, it is still an incredibly small percentage of the total user base. Which is the more important statistic to look at to determine where ONE developers time should be spent. I have stated it before, neikeq is open to having it integrated to the editor, but they have way more important things to be doing.

As for your question - yes, VSCode is a better code editor than Godot's built-in one. But GDScript is better integrated with the built-in editor. And I know you're next response to this, "then we should have this!". Which again - neikeq is open to someone doing it. But no one has. It is really that simple. Remember - Godot was designed with GDScript and an internal editor in mind. neikeq has far more important things to solve with C#'s integration than tooling for the built-in editor. Most people who are vocal with C# are experienced C# devs who prefer their own tooling.

[Shadowblitz16]

@Duroxxigar I'm not saying that it should be done right now, I'm just saying it should be done sometime in the future.
Right now I think we need to work on C# stability, but we should probably add this to a C# todo list as low priority.
I do like this suggestion because it doesn't just cover C# but also other potential languages.
I think this is the first step for a builtin C# editor.

[Duroxxigar]

And it is on neikeq's radar, but very low priority.