Lsp-mode: Add support for GDScript

[howdoicomputer]

With the release of Godot 3.2, there is now an option to use LSP to assists developing games with Godot's Python-esque GDScript. Would be neat-o if this was supported so that Emacs could be a better external editor for Godot development.

https://github.com/godotengine/godot/pull/29780
https://godotengine.org/article/here-comes-godot-3-2#coding-tools

Also, support might not be easy to add due to their LSP implementation only supporting WebSockets.

https://github.com/godotengine/godot/issues/34523

[yyoncho]

@howdoicomputer you may search for the topic in the gitter chat - I think that there is already a working prototype but there is no PR for that.

(CC @ofrank123 @NathanLovato @Thorhian )

[NathanLovato]

@ofrank123 was working on some LSP support, but he told me there were a few limitations with the current implementation on the engine's side. In particular, with complete suggestions. I don't know where he's at at the moment or if he is still working on it.

As I said before, while I couldn't write it myself, I'd gladly chip in and sponsor some work on that feature.

Then, I've created a new GDScript mode package to fix issues with other implementations, that were incomplete or broken, but more importantly unmaintained: https://github.com/GDQuest/emacs-gdscript-mode

It's based on the Python mode from Emacs 27, and I'm looking to keep maintaining it, although I'm just dabbling in lisp.

[ofrank123]

Hey, I've been working on adding LSP support, but there's a few annoying bits that I can't seem to get around. The current LSP server implementation is not spec, (it ignores any message starting with the "Content-Length: " header, which is kinda ridiculous), and only communicates over websocket. I think I am going to fork godot and change the LSP to use the TCP server implementation they have already in the core, but I'm back at school so I can't guarentee anything speedy. Additionally, the current maintainer of the language server never responded to my email about this change to TCP, so I'm not even sure the PR would be accepted.

[NathanLovato]

@ofrank123 Geequlim said he was okay to change the server to TCP. Rather than emailing him, you'd better:

1. Contact him on twitter: https://twitter.com/geequlim / You can include me in the conversation, he's always replied to my messages
2. Open issues in the repo directly, because other devs may be able to help there, and more importantly confirm that that's wanted.

If you haven't done any of that yet. Geequlim is a busy guy, you shouldn't hesitate to nudge him with a follow-up message, like "Did you have a chance to check my previous message? May I implement that?".

Also, best tag him in the issues you open on the official repo.

Sounds like in any case, the first step is going to be to fix the LS implementation upstream.

[NathanLovato]

And so according to what I've read, Geequlim already confirmed he was okay with the GDScript LS using TCP instead of websockets.

[NathanLovato]

Also, if you feel like you can't work on that now, or you'd rather work on something else, tell me, and I can try to find a dev to do that work.

[yyoncho]

Just want to mention that if TCP support won't be added soon we could implement ws support.

[Thorhian]

I'd totally do it but I don't really have the expertise (and at times, time) so I can't really give any promises.

[CyanBlob]

As a vim user that's ended up here, I'd prefer changing the GDScript server to TCP so that vim's LSP clients (such as COC) can benefit as well. TCP in general seems to be more widely used than websockets for language clients in general

[NathanLovato]

@yyoncho Would that be quite a bit of work? If it's not too much of a burden (implementation + maintenance), why not? But if pretty much all other servers use TCP, it would be a bit of a pity to support web sockets just for one language server, wouldn't it?

[yyoncho]

@NathanLovato IMO it depends on the maturity of the emacs web socket library. Lsp-mode is very modular and it won't be that hard to implement support for one more transport.

[NathanLovato]

Okay. Well, if TCP is the protocol most, if not all language servers use, I'd expect that most editors would then expect and support TCP when it comes to language servers. I'll see how the discussion goes in the godot engine repository, it may change on Godot's side.

[ofrank123]

I'll make a fork and start working on TCP tomorrow.

[NathanLovato]

Great! Be sure to open a WIP PR early on, so people know you're on it 🙂

[CyanBlob]

Great! Good to hear. Do you think there's any chance you can keep both TCP and websockets? That way the VSCode plugin doesn't need to change

[ofrank123]

I'm gonna start by just switching to TCP, I don't think there's a non-trivial way to go about having both.

[NathanLovato]

Also two things:

• Most of the lsp client in the VSCode plugin is about treating messages (vscode doesn't seem to have something that does the job for you like emacs-lsp), the connection to the server itself is a little boilerplate code.
• So the cost of maintaining two connection methods side-by-side would likely be higher than changing the VSCode and atom plugins.

[ofrank123]

I agree with @NathanLovato here, the choice to go with websockets is confusing and swtiching over won't be difficult for the implemented plugins. I have no knowledge of how either atom or vscode works, so someone else (hopefully the current maintainers) would have to switch over.

[ofrank123]

I have opened up PRs on lsp-mode and godot for the changes I'm working on, here and here. I currently have all of the major features working in emacs, but I think my code needs some robustifying and I need to add multiple client support for the TCP server.

[NathanLovato]

Great, thanks for your work!

[ofrank123]

Good news, everything seems to be working for both emacs and vim!

[yyoncho]

Already fixed