Make the Rascal VSCode plugin even better

[PaulKlint]

First of all, the VSCode plugin for Rascal already gives a fantastic user experience. Here are some suggestions to make it even better

Running a Rascal module via the Explorer

Right clicking on a file name in the Explorer gives a menu with entries:

• Run Tests
• Debug Tests
• Run Tests with Coverage

can we make these work for Rascal?

When positioned on a Java file the following entries are added:

• Run Java
• Debug Java

It would be very convenient to have entries

• Run Rascal
• Debug Rascal

Debugging

• Starting the debugger right now is uncool. The only option that really works is typing :set debugging true in the console

• Jump over a conditional statement jumps over the whole statement rather than over the condition (a long standing, very irritating, issue)

• It would be very convenient during debugging to display the text AND the ParseTree when showing values when hovering over a variable of type ParseTree.

[jurgenvinju]

These are very nice ideas. Thanks

• Debugging steps are fully controlled by grammar annotations in Rascal.rsc.

  • because the annotations end up in the parse tree productions they influence node identity, which means careful bootstrapping. But it's not impossible!
  • If we fix a few of these issues in one go we can coordinate between the interpreter and the compiler.

• Many Popup menu options are a design artefact carried over by the JDT from eclipse. I would propose we use the more LSP-native interaction designs like lenses, hints and code actions.

  • A code action for running the tests of the current module, for example, or including all modules it imports would be great. Or a code lens next to the "run in terminal" command?
  • This makes features more easily discoverable for users and also prevents the enormous menus that eclipse ended up with.
  • Test coverage would be nice as a hint or a lense: each function could report on it's coverage by the latest test run?

But these suggestions, however we design them, sound to me of the "how did we ever do without"-kind.

[PaulKlint]

As already mentioned above, popup menus are used widely in VsCode to start execution, debugging etc. It maybe the case though, that these interactions are VSCode-specific and not LSP-specific.

In addition, I think that the use of code lenses to start execution (although funny) has its disadvantages:

• the module in question needs to be in een open editor (opening this editor requires extra user-interaction that VSCode so brilliantly avoids in many scenarios).
• you have to search the text of the module to find the code lens since it depends on the content of the module; this is extra cognitive overload of the user.
• the text of the lens is tiny and easy to miss.
• an arrow icon in the left-hand gutter might be better (as VSCode does, for instance, for starting tests)

[jurgenvinju]

I'm guessing these menus are Eclipse specific, because the Java support in VScode is fully based on porting the Eclipse support for java. The rest of VScode and the LSP works more with commands under keyboard access and editor features.

But that's very true what you say; the lenses don't work for the resource views at all. And that's not useful.

Perhaps we can infer popup menu entries for files, from the lenses that are tagged to the entire file and have the best of both worlds. That way we program the feature once, and we get access in the UI in several useful ways.

[DavyLandman]

There are a few things I want to add. And I agree with Jurgen, some of the patterns you've observed Paul are specific to how the Java VS Code extension has designed the interaction, which indeed has some Eclipse style interactions in there.

I find that the extension documentation of VS Code has quite some interesting guidelines for extension authors. An often repeated advice is not to expose the same feature in multiple places. But specifically around execution & code lenses & debugging, there is not a real UX guideline yet.

If you look at the debugging user guide it's all about the launch configurations. This is a point where developing the rascal debugger we spent quite some effort on (@yami2200 spent quite a few weeks on just this topic), so let met share those insights.

1. The normal run/debug assumes a program is started from VS Code, runs, and terminates.
2. There is no way to launch or debug an application without an entry in the launch.json file, with the exception that if there are no configurations in the whole workspace, there is some fallback behavior that you can configure. Rascal already does this, if you press the "play" triagle without any launch configurations, you'll get the REPL with that module active.
3. We can, but with quite some work, automatically generate launch configurations, this is what Java extension does.
4. REPLs are alive much longer than a normal program launch, and the UI will always have this "active launched thing" bar on the top of your editor, since it's still a running debug process.
5. the :set debugging true (also discussed in usethesource/rascal#1994 ) was chosen since we wanted to soft launch the debugger. we need better discovery of it.

I think one of the problems is that right now, the way we "launch" rascal programs (import into a REPL and run it) is not really aligned with launch configuration assumptions in VS Code. Especially if they stay open for a long time. We could investigate how other extensions with REPLs have solved this?

Aside from that, I agree we need to make debugging more discoverable. But it will involve some effort, especially since we're not a regular process that is launched. Maybe we should model the "attach" style debuggging configurations for remote java processes. But we would have to figure out a way to automatically generate them, without spamming the launch configuration.