I am not sure what is the current state for support of vscode so apologies for cross-posting this topic but I was wondering if anyone has this working on their machines. My SuperCollider version is 3.13.0.
Also, vscode requires a lot or ‘permissions’ on your machine. I feel much safer installing a free software build without Microsoft tracking additions. This way, you know what you are using!
The other ones are just syntax highlighting, Scott’s extensions is trying to make a LSP (Language Server Protocol) integrated with the IDE. They are not quite the same thing.
The only one that provides merely syntax highlighting is the red-ish one, made by “salkin-mada”. The other two are indeed for working SC code, the first is running all code that is enclosed in s.waitForBoot function through the terminal communicating with the sclang executable. The SCVSC is closer to IDE service for SC coding as it offers various coding-related tasks. If the Language Server option of vscode-supercollider could also work with the latest stable instead of the current developer version of SC, which I think is the state now, then it would help to have the server providing information about code-completion syntax highlighting and code analysis so that would be closer to the native IDE.
That sounds very appealing! How does the html help document system work in vscode via both Scott’s extensions and scvsc? If SuperCollider can be used in vscode in the same way as in SC-IDE, then it is worth trying to use one of them, as I often use vscode to find and replace text across files in certain folders.
Sorry to ask this without digging into it myself until I have enough experience with these extensions. Honestly, I tried to use them but gave up. Not so easy to me….
I added info to the VSCode extension readme, but just to recap here:
The Document class provides an interface between a given IDE and sclang itself. Unfortunately, the current design expects that each IDE has it’s own version of this class - they have to be swapped out. Launching sclang from the SCIDE causes it to use a built-in Document class for sc-ide, which conflicts with the VSCode one if you have the quark installed.
Ultimately, the design of Document needs to be improved so it can support more than one IDE for a given sclang-conf.yaml file. Until this is fixed, you’ll need to use a separate sclang-conf.yaml file for each IDE (e.g. SCIDE and VSCode) as a few people have suggested.
Refactoring the Document class is extremely worthwhile work for anyone who want to work on a bigger class library task, I’m happy to outline a slightly better implementation that would resolve these problems and clean things up. I don’t think I’ll be able to get to this work soon, there are some basic stability / usability things in the VSCode extension that feel higher priority right now, but if this is a significant blocking issue for a lot of people I’d happily prioritize it a bit higher.
I’ve done so (two yaml config files), I am running in new errors, and have documented them on GitHub. I am very appreciative of all the help to bring me up to speed with all of this, and I hope my stumbling will help others get it going. @Sam_Pluta is a great advocate and since he seems to has sorted students on this, maybe he has a fool-proof list for me - he knows how foolish I am indeed
My advocacy is aspirational. I want it to work because I think this is the best way forward. I got it working for myself, but I didn’t think it was there yet. But this was 6 months ago, so many thanks to @scztt for continuing to work on it. Once it is there, I will switch and never look back.
I can also confirm (as semiquaver did) that placing LSPDocument.sc into an editor-specific folder (scide_vscode) works.
Refactoring so that Document is basically a stub at the top of the hierarchy, with subclasses providing the real functionality, is a good idea if it reduces the amount of copy-pasta. But it isn’t strictly necessary just to get it work.