Request re: command line prompt
or above the post window?
Sure, making this configurable is even better. But the result of the executed code will still show up at the bottom of the post window. Unless that is configurable too 
true! command line prompt under the Post window is more convenient!
Um… I am not ready to use SCNvim (and perhaps sclang in vscode). You have overestimated me. For me, a non-programmer user, SC-IDE seems to be the best.
Anyway, is implementing sclang in an existing editor easier than implementing the features listed here in SC-IDE? I wonder why the effort is focused on implementing sclang to other editors.
Methods at the beginning of a line starting with . should be intended:
Just my 2 cents as a supercollider newb who is also a software engineer, but I’d vote to focus on the vscode plugin (and language server in general for integrating with neovim etc.) and ditch scide. The only argument I’ve heard for continuing work on scide is that it’s more beginner friendly, but I’m not convinced the difference in difficulty between scide and vscode is significant enough to make it worth maintaining a huge project like an IDE.
SuperCollider is not an easy platform to learn, so I find it hard to believe there are many people out there who can write sclang but not use something like VSCode in a very basic way? My sense is these are non-overlapping groups.
Playing devil’s advocate: I can imagine there might be some intimidation factor of using a “professional” coding environment like VSCode for non-programmers. I also might be misunderstanding what your average non-programmer is doing in supercollider. But I also fail to see why SC would be the platform of choice if someone is code averse. I think it would be a very confusing first programming language to learn, and there are so many other great platforms out there catering towards non-professionals who want to gently ease into the technical side of computer music (reaktor, max/pd, sonic pi, tidal cycles, etc.).
Anyway, bit of a rant but I’m curious what others think about this. To me, the problem seems to be partly about how to potentially guide people when setting up vscode, and partly about choosing which users to focus on. You can’t make everyone happy, but you can certainly make everyone unhappy. My hunch is that spreading dev efforts too thinly generally results in the latter.
edit: Just clarifying that I’m only advocating for VSCode here as the entry point for sc. Not neovim etc., that would be cruel and unusual 
From the beginning, JMC stated in the original paper that the intended user was not the computer scientist, but rather the Max/MSP user who wanted to explore more abstract concepts. This principle is the foundation of the community and one of the reasons for the project’s success. We must not forget that.
I’m not against any of the development, just reminding this important aspect. But maybe vscode is not that intimidating? I don’t know…
Even some of the talk about making sc more like python with namespaces etc seems to contradict this. The person would need to learn as much as a first year CS undergrad if all that is changed…
McCartney, James. (2002). Rethinking the Computer Music Language: SuperCollider. Computer Music Journal
That is interesting context, I never would have guessed! Thanks for sharing.
I guess my personal experience with SuperCollider might not be typical. Is there any data on how people are actually using supercollider? E.g. surveys. (not to derail the topic. I’ll do a search myself)
I mean, the inspiration of SuperCollider language is Smalltalk, that was not an “industry” language like big corporations create today, but very innovative and explorative. It’s interesting to think about the history of it.
In my experience, most of them are musicians, and learn computer science very slowly compared to a full time CS undergrad.
Here is a user survey from 2019…
Interesting. Great source.
I think all those questions that JMC raised in his paper need to be discussed again if any major change is being planned. Otherwise the project just becomes something else.
I very much agree with dalip here. The thing is, it used to be difficult to set up external editors like vs code. Now it is easy. Literally 5-10 minutes and you are using a top notch editor from which you can program hundreds of languages. The game has changed. I am going to put my money where my mouth is (what a weird phrase!) and teach my sc class this spring from vs code. I’ll let you know how it goes.
Sam
An opinion and a question
I would like to say that there is at least one more argument:
I may be wrong, but SC-IDE seems to be the only sclang-supporting editor with full documentation navigation support that runs on MacOS, Linux and Windows. I hope it will continue to be maintained, even if no new features are implemented.
QUESTION
Does VScode, emacs or any other sclang-supporting editor support this indentation?
I think the code style guide should be changed if there is no sclang-supporting editor that supports it.
Where did you get this idea…? This just isn’t true. You can look at the readmes for scvim, scnvim, scel, and see that they support this. The LSP/vscode integration will also support it if it doesn’t already.
This is off-topic, but you can open another thread to discuss changes to the internal SC project code style if you want.
FWIW, I’m using vscode for nonproduction SC mucking about, with the intention of teasing out bugs through typical usage, and… let me say first, scztt has laid out a really impressive framework, and I fully believe it will get there, maybe in a few months, almost certainly in a year or two.
But it isn’t ready yet.
Native vscode indentation is almost right. One glaring problem is that opening a block with open-paren causes the contents of the block to be indented. Best workaround I could find is to type the contents first, and add the () delimiters afterward. Better indentation will depend on scztt’s other tool, sclang-format, which I tried and failed to build. Native vscode indentation is mostly usable, just… slightly off for SC in a few places.
Sometimes completions fail to be delivered – e.g., just yesterday I started typing “LimitedWr” expecting the completion “LimitedWriteStream” to pop up. But… nothing. Sometimes the fuzzy string matching for completion is weird, preferring far remote partial matches over near-exact ones. I’ve also seen the language server go unresponsive at times, for no apparent reason. No error, just, it stops offering completions altogether. I didn’t find any way to deal with that other than to quit vscode and relaunch.
I won’t try to rehash everything I’ve run into (I’m not at the computer now, for one thing). But IMO the SC vscode plugin hasn’t reached a beta stage yet. Maybe it’s close but it doesn’t feel to me like “almost ready and we’re putting it in front of users to refine the ux and find the really odd things that 1 user in 1000 will hit”; it feels like “here’s a good start but we need more eyes to find the things that need fixing (and more devs to dive into the language server).”
hjh
Sorry for assuming without trying them all.
My recent successes are installing LSP/vscode on MacOS, Linux and Windows, and installing the sc kernel for Jupyter Lab on MacOS, Linux and Windows. Both do not support Windows.
More than 13 years ago, when I was a beginner, I tried using scel and scvim, but returned to the official binary release because they are not as convenient as SuperCollider.app. I have tried to install them from time to time over the last few years, but SC-IDE is still my main tool. As for scnvim, I have not even been able to install it successfully on MacOS. The installation instructions are a bit difficult to follow. So I have not tried to install it on other OSes. (I am not much of a beginner. I can build SuperCollider from source on MacOS and Ubuntu).
To replace text across files in SC project files, including my writing in schelp file format, I had used Atom, Brackets, BBEdit, TextWrangler, Dreamweaver, Sublime Text and Textmate, but now only use VSCode.
I am really happy with LSP/vscode and sc kernel for Jupyter Lab.
Especially for large projects I would like to switch to LSP/vscode completely, but I think in LSP/vscode and sc kernel for Jupyter Lab something should be reworked to completely replace SC-IDE.
(I am not judging other editors. Emacs with i3 seems really great to me, but I have not tried it.)
Until then, I think it is not bad to post in this thread, because
You don’t have to try them, it is in the Readme files for the projects which are easily accessible on github.
I was talking specifically about requesting changes to code style. That is a separate conversation to which IDE people are using or want to use.
Ah, sorry! I know your intention! This was not aimed at you. sorry again…
Have you checked how much memory vscode requires in a supercollider session? In general vscode consumes a lot of memory, there are reports of 2 to 3GB for a few opened text files. So, if one has limitations in that area, it would be better to use another editor during stage performance.
Maybe this idea of an editor for programming, and a lighter option for performance isn’t bad. Nothing is worse than problems on stage.