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
1 Like
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
- a survey in 2019 showed that many users are using SC-IDE at that time: Which IDE do you use?
- I think there are still many users who rely on SC-IDE.
- I also see that there are new PRs for SC-IDE on GitHub. I would like to see these PRs accepted.
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.
1 Like
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.
Been using it for months. Not going back. The upside far outweighs the few rough edges left to smooth over.
Sam
1 Like
Did you look and make some sense of the LSP code behind it? We should try to grasp it at some point. So we can start to improve and even write plugins.
Two weeks ago, I made my first change in another vscode extension to fit what I would prefer (Haskell-interactive) also to see how difficult that would be. It worked, simple changes, even though I had never coded in typescript before…
I agree with this suggestion – people who would like vscode to be a viable replacement for SC-IDE could move this forward by reporting and fixing bugs. The language server is even in sclang itself, so the entry barrier is relatively low. (The vscode plugin isn’t sclang, but the language server is.)
hjh
1 Like
It is on my list of things to do. Hopefully I can get to it before school starts up again.
Sam
2 Likes
This, btw, I have to amend – I did get it to build successfully, though I’m mired in end-of-semester tasks and won’t be able to do anything with it in the immediate future. Looking forward to seeing how that works.
hjh
The repo clang-formt depends on has moved. Also, install antlr. That’s all you need, it seems.
cd external
git clone https://solitarybees.us/hadron/sparkler
cd ..
to install antlr dependency, if on macos:
brew install antlr
To build (from the root of the sclang-format dir):
mkdir build
cd build
cmake ..
make
1 Like
I did it.
However, the sclang-format does not respond by the following command in terminal:
./sclang-format -t /Users/prko/Downloads/test.scd
By pressing cmd + ., I can return to terminal prompt:
Moreover, I do not understand why the following command does not work:
sclang-format -t /Users/prko/Downloads/test.scd
I don’t know, I think we need to ask Scott about it.
One thing you can try is to checkout the exact commit of the dependency:
cd external/sparkler
git checkout bd9d0df
cd ../..
And then build again (in this case, try a clean make with a new folder)
Done again, but same result! Anyway, thanks!
This is about the Unix command shell’s PATH variable. Should be plenty of information online about it.
Certain paths are included by default in the list of locations that will be searched, to find the executable for a command. The build location for sclang-parser is naturally not one of these default locations, because no system could anticipate where you will put the repository. So you could add the path manually (see online documentation) or specify the path when running the command (which is implicitly what happens when you cd to the directory and run ./sclang-parser). A final release of sclang-parser would include an “install” stage (as SC’s cmake configuration does) to copy the executable into a default location. But, as this is a pre-release tool, this hasn’t been done yet.
hjh
1 Like
@prko I did a quick test and it seems to work (it outputs something), it uses standard input and standard output. It does not have an “in place” option.
cat ~/scwork/my-file.scd | ./sclang-format
EDIT: If I’m not mistaken, I thought there was a convention for supercollider code to always indent with four spaces, not tabs. Is there such a convention, or that’s my imagination?
(sorry, I think I replied you in the wrong thread)
1 Like