GDScript code highlighting

[DavidCooperWCU]

Made necessary changes for GDScript 2.0 highlighting.

Documentation was updated to include runestone support, but runestone activecode isn't working yet. (Right now it's set to work with JOBE, but I'm leaning towards a client side solution more like sql.)

Prism has GDScript 1.0 highlighting, so I had to add some custom javascript to handle code with @.

Latex's listings library supports python, which is pretty close, but not a perfect match.

[rbeezer]

Visually, I think this looks good. A few comments, some about undocumented conventions (sorry!):

• Generally, we would prefer you rebase your contribution on master privately before making a PR. I think the merge commits are fine, they'll go away when I rebase, but usually we do not want them in the way. Rebase conflicts are pretty rare, the code is quite modular.
• With one (of few) commits, new work can be added on, I can combine as part of merging. A force-push is usually fine. We generally do not have others adding on to a PR.
• Let's not inject the JS this way. For one thing, it does not read so well, with CDATA, etc. But more important, we have never used this device. It should be in its own file that gets read in via a script tag. Location is good, and the before-tokenize should be kept.
• We could have a boolean variable like $b-has-gdscript that is a stricter test than $b-has-program and only load the JS as needed.
• Let's add a code comment before we use Python for LaTeX listings - just so there is no confusion in the future.
• Timing? Should I wait for an all-clear on Runestone work, or should this go in as soon as it is ready?

Holler if any of this needs more explanation. With changes, I can do a more thorough review.

[DavidCooperWCU]

I added a separate gdscript-prism.js file to inject the syntax highlighting.

I'm not sure how to get syntax highlighting working in the activecode. It looks like it uses code mirror, and I think there is a gdscript module for code mirror. So, I'll need to look into that for a future version.

There are now 2 examples in the sample book as well as the godot-shell folder that holds the godot wasm files.

Sorry about the merge commits. In the future, I won't update the branch after making changes to it.

I submitted a pull request for the rs changes, and I'll let you know when it goes through.

[DavidCooperWCU]

I also had some trouble with indentation with a code in a program in a statement for an activity. (Maybe it's all the nesting.)

[DavidCooperWCU]

The JavaScriptBridge filtering is to address the largest security concern with using a Godot WASM file.
This concern is that GDScript can call arbitrary javascript, which could potentially open up the site to known attacks.

The filtering restricts JavaScript calls that aren't specifically postMessages that have a JSON dictionary as a payload, and a known origin. As long as eval isn't used on the JSON dictionary, this should restrict calls to actual GDScript instead of allowing arbitrary javascript code to be run in the WASM.

[rbeezer]

Is the Runestone side ready on this? @bnmnetp was just asking.

Is this ready? You could mark it as a Draft if not. But post here when it comes off being a draft, as I don't always see that. Thanks.

[DavidCooperWCU]

@rbeezer, yes. This is ready, and the Runestone side is ready also, @bnmnetp

[rbeezer]

Hi @DavidCooperWCU! I've given this a first pass. Some details to work out, like the correct XSL, publisher options, etc. Nothing we can't get straight.

Binary blobs (*.pck) make my ears prick up, for multiple reasons. I am posting a few questions on our pretext-dev list. I hope you can participate in that.

[DavidCooperWCU]

@rbeezer I'm happy to make any changes you feel are necessary. Just let me know. I did respond to your message on pretext-dev. I have added a modest amount of security guardrails for the binary code and the arbitrary gdscript that is allowed to run. The raw javascript that is allowed to run based on a javascript bridge is limited to those sending gdscript programs to be run, so no random javascript can be evaluated. Code needs to be either on the server hosting the iframe or on runestone.academy for it to be loaded, but we may want to do some adversarial tests on that.

[DavidCooperWCU]

I have the .zip working in the wasm. The next step is to have a way of converting the directory for a gdscript activecode interaction to a zip during the pretext build.