Language Server: workspace management feedback

Development
1

I’m slowly adding more workspace-related functionality to the sclang Language Server and VSCode plugin (SuperCollider VSCode / Language Server Protocol support). For those unfamiliar, a workspace is just a folder or folders you are currently working in, which in general act as a sort of organizing unit when you’re editing code with the language server - for example, if you do a file search in your IDE, it will search files in your workspace.

I want some feedback and how folks would like this to work, and to check some of my assumptions. With that in mind:

How it works now

  • There is one sclang instance per workspace (in VSCode, this generally corresponds to one window with e.g. a project navigation pane and multiple tabs). Creating a new workspace in turn launches a new and totally separate sclang instance, which corresponds to the semantics of current Atom/Sublime/VSCode editors.
  • VSCode assigns each workspace a unique server port range. so multiple sclang instances can run their own servers without colliding. Note that this is IDE specific behavior, so this would need to be implemented in e.g. Vim in order to have this behavior for other editors.
  • VSCode will optionally look for a sclang_conf.yaml in your workspace, and use that instead of the global one - this can be configured in the settings.

What I plan to add

  • An option to run / not run the global startup.scd file.
  • An option to run / not run a workspace-local startup.scd file.
  • The above can both be true - with a multi-root workspace, this would result in:
    • The global startup.scd being run first
    • Each workspace-local startup.scd file being run
  • A full “workspace sandbox” mode to ignore the global / system extensions folder completely, which would mean your local workspace sclang_conf.yaml should fully define everything that’s loaded (this would require a fix for UGen loading in scsynth/supernova).
    • This would also store things like SynthDef caches and Archive files in the workspace, in something like a /support directory.
  • An option to launch in “safe mode”, which would be a totally blank sclang_conf.yaml and no global extensions. This can be useful for recovery from compile errors.
  • Startup/shutdown actions (including startup.scd) would move to being executed by the language server, e.g. they would only occur once an LSP connection is made (obviously this would only be if the LSP is being used).
  • The Require quark will work correctly and intuitively within workspaces (e.g. the current workspace will be the default search path).
  • If possible, an easy way to differentiate which sclang instance is which when running multiple (e.g. changing the process name on mac, or a menu indicating the name/path)

Some of these options, as well as other sclang functionality, might not work appropriately for multi-root workspaces (e.g. a workspace that has multiple root folders) - I will make things work where they make sense (e.g. startup files), but there will be some limitations overall.

I’m curious what people think about some of these workspace management options. Would you make use of workspace-local startup files? Is it important to have a more complex cascading “global + local” startup files? (And what order are they run in?)
How much would people desire a mode where you can make a single folder effectively it’s own fully self-contained SuperCollider environment (which would make isolating single pieces a lot easier for e.g. performance or sending to someone else)?
Is there other obvious functionality I’m missing from the workspace concept? Should a workspace have a folder for .sc files that’s included automatically? Should recordings be placed in the workspace and not a global location (this is what I do locally…)?

(And, fwiw, everything described above would be LSP-only, and opt-in)

3 Likes
2

I think it’s a very idiomatic idea to many people’s workflows. And the workspace configuration must have priority, or be the only one.

How much would people desire a mode where you can make a single folder effectively it’s own fully self-contained SuperCollider environment (which would make isolating single pieces a lot easier for e.g. performance or sending to someone else)?

I would support that.

–

  • Are other emacs users with some Elisp proficiency interested in making a plan, and dividing the job into smaller tasks?
3

A lot!

That’s class files right? I’d love to have a Classes/ folder that can easily be shared, but this would require relative paths in sclang_conf.yaml which we don’t have, right? I’m just thinking of a very confusing case where the LSP thinks there are classes, and sclang does not. Particularly if this is to aid distribution of work.

Do system links work?

1 Like
4

I would go for a full self-contained workspace.

5

All the workplace stuff would be amazing. Any improvement on how we distribute our pieces would be so welcome. The self-contained folder approach is one I have used (but with 3.13 there was a bug that didn’t let you put extension in an external folder (fixed in the dev build), and this messed me up in rehearsal of my laptop ensemble piece (for example)). Just being able to pair things down to a minimal library for testing would be so great.

Multi-startup file sounds nice. I wonder if it might be better for the local workplace startup file to over-ride the system startup. Or if you want the system startup file to run, you tell it to do so in the local startup. At the top of the file or at the bottom.

I like having the option for recordings to go to the workspace.

I am loving the VSCode support scztt!

Sam

1 Like
6

Sam and others,

What is possible right now? Having a configuration file inside the workspace folder, with links pointing to that folder, would be supposed to work right now or not? I tried once and got strange problems.

7

I don’t think what you are saying works currently.

The thing I was referring to was that in SCIDE/VSCode/etc you should be able to set the UGens path in the startup file like this:

Server.local.options.ugenPluginsPath = [
	thisProcess.platform.classLibraryDir.dirname+/+"plugins",
	"~/Library/Application Support/SuperCollider/Extensions/".standardizePath,
	"/Users/spluta1/Documents/faust/CompiledPlugins_M1/".standardizePath];

This works in the dev build, but not in 3.13. It bit me in the ass when I tried to have a laptop ensemble of undergrads load my piece. I thought I was so clever!

BUT, if scztt gets this working with workspace folders, this will be a giant leap for SCKind.

Sam

8

I think it is generally very good and have already reported what I miss on your Git-Hub repository.

Users who only use the SC VSCode / Language Server Protocol support will not have the problem described below. However, users who also use the SC-IDE may have such problems.

Only I sometimes have a problem using the Help Document on SC-IDE as follows:

  • launching SC-IDE after using your SC VSCode / Language Server Protocol support
  • launching SC-IDE while using your SC VSCode / Language Server Protocol support
  • using your SC VSCode / Language Server Protocol support while SC-IDE is being used

I have a recurring issue:

The only way to resolve the problem seems to be to reboot the machine.