Add debugging hint to repl help

[urbanfly]

It is not easy to "discover" how to start a debugging session in VS Code.

It would be nice to describe it on this page
https://www.rascal-mpl.org/docs/GettingStarted/RunningRascal/VScode/

This Stack Overflow answer/comment is how I discovered it.

[DavyLandman]

Hmm, yes, the discoverablity of the debugger is low, which was a bit intentional, as it has some strange behavior we're not completely happy with. But in many ways, it's nice.

However, maybe we should do this change in rascal-language-server, as that's the only place where we support this command. We've extended the :set command in a similar way there.

What do you think @jurgenvinju ?

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 49%. Comparing base (4aaee5d) to head (dc052f8).
Report is 2 commits behind head on main.

Files	Patch %	Lines
src/org/rascalmpl/interpreter/Evaluator.java	0%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##              main   #1994   +/-   ##
=======================================
  Coverage       49%     49%           
- Complexity    6290    6304   +14     
=======================================
  Files          664     664           
  Lines        59558   59559    +1     
  Branches      8639    8639           
=======================================
+ Hits         29428   29466   +38     
+ Misses       27921   27879   -42     
- Partials      2209    2214    +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jurgenvinju]

If we add it here we should make it conditional on the existence of debugging features. I do agree about the low discoversbility.

Another solution would be to activate the debugger when the first breakpoint is set.

[DavyLandman]

Another solution would be to activate the debugger when the first breakpoint is set.

There were quite some limitations on how to start a debug session from VS Code, especially since there is no launch/debug configuration in the project. If we start generating that for every project, it might be doable, but still, what if I have 3 REPLs open, to which one do you connect?

We could also just print a message in the repl at the start of it? Like: did you know...

[urbanfly]

We could also just print a message in the repl at the start of it? Like: did you know...

That would be better than nothing, but "start of it" disappears pretty quickly. But if you mean "after all the initialization and just before user input", that sounds fine.

[urbanfly]

Any advice on how to improve this PR?

This is my REPL just now - after not debugging for several weeks...

rascal>:help
Welcome to the Rascal command shell.

Shell commands:
:help                      Prints this message
:quit or EOF               Quits the shell
:set <option> <expression> Sets an option
e.g. profiling    true/false
     tracing      true/false
     errors       true/false
:edit <modulename>         Opens an editor for that module
:test                      Runs all unit tests currently loaded

Example rascal statements and declarations:
1 + 1;                     Expressions simply print their output and (static) type
int a;                     Declarations allocate a name in the current scope
a = 1;                     Assignments store a value in a (optionally previously declared) variable
int a = 1;                 Declaration with initialization
import IO;                 Importing a module makes its public members available
println("Hello World")     Function calling

Please read the manual for further information
ok
rascal>:set debug true
ok
rascal>:set debugger true
ok
rascal>:set debuging true
ok
rascal>:set debugging true
Debugging session started.
ok

[DavyLandman]

@urbanfly we should move this towards usethesource/rascal-language-servers as there is where this new command is introduced in the REPL.

For example here: https://github.com/usethesource/rascal-language-servers/blob/3d02641b265a7276082c34836545caf02ff50aa0/rascal-lsp/src/main/java/org/rascalmpl/vscode/lsp/terminal/LSPTerminalREPL.java#L111

But we should also try and change the :set command (in this repo) to properly report unsupported flags, and maybe print out the currently supported flags.

One of the problems is, this code (the REPL) needs to be revised to migrate to jline3, you raise some good points about how this interaction can be improved, but changing the infrastructure around commands (and their relevant help messages) too much right now would be wasted effort, as much will change when switching to jline3.