Implement OpenSCAD LSP (Language Server Protocol) in editor

[elasticdotventures]

LSP "Language Server Protocol" is used by all developer IDE's to support things like intellisense. LSP provides a common standard between applications so that every code editor doesn't need to write support for every language.

https://microsoft.github.io/language-server-protocol/

There is already an openscad LSP built for vscode and linked below:

openscad

The advantage of implementing the LSP approach to the internal cadhub editor is that it will allow the same editor to quickly drop in LSP providers for even more languages (such as .gcode or .svg)

[t-paul]

In my opinion, the OpenSCAD LSP belongs into openscad itself (https://github.com/openscad/openscad/pull/3635).

[elasticdotventures]

In my opinion, the OpenSCAD LSP belongs into openscad itself (openscad/openscad#3635).

The LSP plugin in (Antyos/vscode-openscad) is imho 'most updated' for vs-code.

It's certainly appropriate for @antyos Antyos/vscode-openscad and @Tomatower Tomatower/openscad both be tagged & may with to participate in this discussion.

@t-paul I totally agree with you that LSP and perhaps others should be hosted in openscad org account from a trust signalling perspective. I can't say if it makes more sense as part of the openscad monorepo.

I was thinking perhaps a smaller git template repo that can be cloned & contributed to. The template behavior doesn't download not-necessary history of commits and should integration tests for all the engines be better/faster/cheaper if they were unified OCI podman (formerly docker) builds etc. This makes it easy for people to make small contributions of new objects or polymorphic syntax. Using git submodules the repo can link to existing repos but I would hate thrust submodules into openscad/openscad since people frequently have opinions on that. (Usually better to let sleeping dogs lie)

If you imagine all the versions of all the OpenSCAD tools, each having their own linkage into OpenSCAD itself, the integration tests could become a massive undertaking very quickly since it is a many-to-many test 'state of the OpenSCAD' ecosystem. It makes sense to incubate these ideas outside the OpenSCAD/openscad repo (but possibly within the openscad organization certainly).

I can do dev/ops ci/cd type build actions, and since imho openSCAD has higher ratio of persons with parametric modeling expertise than git-savvy coders & ops. I see openscad suffering from lack of curation & git-expertise, there is certainly an opportunity to improve things including LSP interop.

I expect many of the openSCAD contributors are simple-folks looking to do some quick parametric modeling & many wouldn't know the --template capability even exists in git. The @openscad/openscad monorepo is actually not well suited as an ambassador to onboarding people to it's own technology. I will attempt to address what I see as some of these deficiencies but I worry about being too opinionated so I will only try to practice word precision to try and avoid being labelled a heretic, I'm an openscad reformist, not a heretic. 🤣

As a reformist - I believe there is too much sprawl and lack of coordination spanning openscad communities - it presents a real and signficant hinderance to getting started with openscad, .. simply figuring out which versions of which plugins to install, testing compatibility, then finding objects, learning all the discombobulated syntax & jargon etc. it's a huge amount of yak-shaving that each new openscad community member must undertake to join and that bothers me. Certainly things can be done to make that engagement & onboarding into OpenSCAD easier.

Today as part of my yak styling & self-flagellating-toil I spent my day sending pull requests to contact all the authors of any not-presently maintained VS Code LSP plugins in the VS Marketplace to get status updates ask them to sunset if they aren't actively developing.

I'm going to try and at least start the conversations in each community implementation about which OpenSCAD projects are and aren't planning to do future LSP implementation on their roadmap, so at least this idea can begin actually incubating and hopefully everybody who might have an opinion gets to have a voice.

Ultimately I can implement git build actions that keep repos in sync, do integration tests, and so it's simply a matter of governance in each of the projects to find out their intentions, if that is desired. I'm just not going to waste my time building anything unless I know the commit is welcome by the author(s) of a project.