Checking on maintenance status

[armsnyder]

Hi there,

First of all, thank you for your contribution to the Godot community and for thinking of us non-VSCode users 😄

Is there appetite to continue maintaining this project? It looks like development was active last year but may have been stalled due to the need for a rewrite. Since there were false positive error diagnostics, I was inspired to bootstrap a .gdshader LS for my own use recently. I'm wondering if I should invest time into making it more feature-complete.

[GodOfAvacyn]

Hey dude - I honestly forgot about this project for a long time and was reminded of it by this notification. Sorry! I was in grad school and didn't have the time to polish it up. I have been thinking of finishing the rewrite. Do you have experience with Rust / would you like to help out? Alternatively I could close this one and contribute to yours, since your landing page & roadmap is a lot more fleshed out than mine ever was 😅.

[armsnyder]

Oh hey, thanks for taking the time to reply. 😄 I have limited Rust experience, sadly. Never mastered the borrow checker. I imagine most Godot users involved in writing GDExtension libraries are doing it in Rust? I'm biased toward Go as being more contributor-friendly, but have not validated this.

For a niche LS like this it's hard to find a contributor base, so we should reduce the maintenance tax. On the LS I bootstrapped the first thing I did was get an end-to-end test and automate the releases (with release-please and goreleaser) for all major platforms. I'm also a) using minimal dependencies and b) looking into generating the hover and completion results based on Godot's docs.

I'm open to contributing here, with your guidance, if you want to get started on the rewrite. By the way you're welcome to borrow my VSCode wrapper w/ attribution, since it has multiplatform support and code signing. Either way I'm interested in attempting the code generation from Godot docs over in my project first, since I think that will make or break it.

[GodOfAvacyn]

Not sure what other people are making tools in - I know it's at least possible to use GDExtension & rust, but it's still the easiest with c++. Anyway, the reason I chose rust was for the code gen capabilities of the macro system. I preferred having macros be written in the same language as the overall project, as opposed to a templating engine. But you bring up something I hadn't though of before, which was using the actual documentation as a source for code gen. So there isn't a real reason I'm using rust other than thinking it's cool.

I should have a skeleton of the new stuff soon. The primary reason I wanted to rewrite it was to support a more incemental approach to parsing, (very briefly mentioned) here. It mentions attempting to isolate edits to a single '{}' block, then only replace the block in the AST rather than parse a file each edit, which can allows for LSPs running at a smooth 30fps or so, I think. But it also mentions it's probably unneccesary for smaller things... oh well.

Once I finish up the new parser logic (right now i'm testing everything out on a simple LISP s-expression parser before porting over the gdshader logic), I'll push everything here & document it so I can explain anything that needs to be explained, and I'd love some help with everything gdshader related 👍.