find outermost paren doesn't ignore comments

[x37v]

open

(
  //(
  "got it".postln;
)

:call SClang_block() anywhere inside gives an error about unmatched paren

closed

(
  //)
  "got it".postln;
)

:call SCLang_block() on the "got it" line gives an error about unmatched paren as well, if you eval on the //) line, the block block is sent to sclang and you get this error:

ERROR: Command line parse failed
-> nil
ERROR: syntax error, unexpected $end, expecting ')'
  in interpreted text
  line 3 char 1:

Because, I assume, the block that is sent is:

(
  //)

[kneitinger]

Weirdly enough, I consider this to be a helpful feature...

It's totally possible that I'm missing something about calling sclang from the command-line, but in all of my scd files, I've commented out the parens due to syntax errors when executing sclang my_super_cool_synth.scd with block parens.

With the parens commented in the behavior you described, I can have the best of both worlds: blocks in scvim and easy command-line running of files.

I wonder if there is a compromise here that can result in a more expected and predictable behavior for both of our use cases.

What if the situation you described was fixed, and blocks like

(
  //)
  "got it".postln;
)

work perfectly and the commented paren is ignored, but at the same time, using a documented token like ///( or //-( , code block delimiting parens could live in a comment. For example

$ cat gottem.scd
//-(
  //)
  "got it".postln;
//-)

would print "got it" in scvim when F5-ed and also print it when ran via sclang gottem.scd.

Curious about other people's thoughts. Is this a reasonable solution? Am I doing something wrong with my invocation of sclang? Does anybody else rely on commented parens being recognized (ideally only block-level ones)?