Microparsons assume all problems are code

[bnmnetp]

@amy21206

Microparsons problems may be useful for Mathematics as well as other natural language problems. However the current implementation assumes that all blocks are code . ??

Here is what a microparsons written in pretext to explicitly make the block look like code looks like.

If the formatting tags are removed it looks fine. But there are cases, such as formatting math or having natural language where you want a word italicized will allow the tags to show through.

This has been solved for the vertical parsons problems and we should make them consistent.

Also tagging @barbarer

[zihan21206]

I see! I'll take a look at it and submit a PR next week to address the issue. Is it an urgent problem? Does this timeline work?

Thanks,
Zihan

[bnmnetp]

That timeline is fine Zihan,

Inviting @rbeezer into the conversation as it may be more complicated and in fact in that example your code may have done the right thing.

I'm not sure if you have tried to make micro-parsons support natural language or math??

[rbeezer]

@amy21206 - I think the root problem here is to provide support for natural language. If a PreText author uses PreTeXt markup in a phrase (such as <em>) then it becomes HTML markup which should be interpreted/rendered when the block is displayed by the Runestone component.

So my screenshot above (which Brad reproduced) really isn't the best example. Holler if you need more clarification or test cases. No particular rush, but I will be totally offline for the second half of the month and unable to help much.

[rbeezer]

Back online and available to help/advise.

Example in the PreTeXt sample article is starting to get attention:

https://groups.google.com/g/pretext-dev/c/Om9ait5EJsE/m/Z0rSKgqQAgAJ

[zihan21206]

@rbeezer Hi Rob, thanks for getting back. I have been looking at how the parsons directives solve the problems, and I believe the micro Parsons are missing the XML processing functions that Parsons have (see parsons.py) and I think that's what needs to be added - please let me know if you think that's how the Parsons issue is solved. However I have not worked with PreTeXt before, so do you mind pointing me to some resources that I can start with, like how to test/build with PreTeXt books? Thank you!

[bnmnetp]

@amy21206 It is not a PreTeXt issue.

It is how microparsons is interpreting the html. In regular parsons we can set the language type to either math or natural, in which case we render the contents of the block as though it was formatted html not as a <pre> tag.

Brad

[rbeezer]

Thanks, @bnmnetp. Right - you should not need to get up-to-speed with PreTeXt to solve this problem.

Can you add some simple HTML markup to an existing microparsons and see if you can have it take effect, along with the remainder of the block not in a code-style font? For example, just wrap a word or two in a "b" element and get it to render as bold?

A "regular" Parsons problem has pre.parsonsblocks with a data-language and I'd guess something similar (or identical) would be part of the necessary changes.

[zihan21206]

Thank you @rbeezer @bnmnetp ! How about I will add a "raw" language option for micro parsons, and also default to it, so html can render as is when it is raw, but can also be shown as html/xml code when language option is set for "html" when needed. Does that sound good?

[zihan21206]

After investigating a bit more, I have one more question about the pretext HTML passed in: does it contain syntax highlighting (micro Parsons should render as-is), or should micro Parsons handle syntax highlighting (micro Parsons wrap spans around keywords based on the language, and then render the full html)? Thanks!

[rbeezer]

For other Runestone components, PreTeXt does no more than mimic the HTML that would come from ReST/Sphinx, so a conversion from PreTeXt markup would not normally do any syntax highlighting.

And I do't think we want anymore PreTeXt Javascript conflicting with Runestone Javascript. Knowls and Sage are enough as-is!