Export the myst markdown renderer as a widget

[rowanc1]

Feedback from @tonyfast (twitter).

I think this would look like a widget-style python package that wraps up a portion of jupyterlab-myst, allowing other apps to render basic myst, without all of the other things that the current extension does. I imagine that this could be used in a lot of different ways -- I am extrapolating a bit feel free to add context @tonyfast!

[agoose77]

I think the easiest solution here is to implement #102, and then an output widget can be used for this. A custom widget that accepts text/markdown could easily be added.

Note that, for #102, we probably want to listen for text/markdown; variant=myst (or at least have that as a setting)

[tonyfast]

I think this would look like a widget-style python package that wraps up a portion of jupyterlab-myst, allowing other apps to render basic myst, without all of the other things that the current extension does.

great summary @rowanc1. thanks

Note that, for #102, we probably want to listen for text/markdown; variant=myst (or at least have that as a setting)

yea, its gotta be the variant, the reason i want a widget is because i don't want myst replacing my text/markdown. sorry, but, at this point, i can't consider myst to be markdown, it is a programming language. this isn't a bad thing, but i'd feel more comfortable using myst in my code cells than markdown cells.

there are probably some really excellent traits to expose. i imagine myst is doing all kinds of inspection. tell me the variables, user expressions, footnotes, definitions, or exceptions. i'm not sure what is under the hood, but i want those. there is likely some useful data that could be stored in the metadata for later reuse, too. the widget would be easier to wire to other widgets and access the broader widgets community using the same observable protocols.

some extras:

• you'd get a nice opt in %myst or %%myst magics.
• when you do this, you might see how :fire: jinja or nunjucks templates might be.

[agoose77]

You'd probably get the mdast, which contains all of this information, though we currently parse this in the view rather than in the model (or rather, it needs to happen JS-side).

[tonyfast]

thats good data, as long as the schema is uptodate. i'd expect you'd have fallback mimebundles for text/markdown and or text/html so it would work independent of myst.

[rowanc1]

This is awesome. Thank you @tonyfast! We have officially registered myst as a variant as of last week, and agree that all of the stuff in MyST goes beyond a markup language, and brings a lot of application logic that isn't appropriate everywhere.

We are trying to be thoughtful about the AST (spec), and I think that is where you are looking to get at mostly? For example, this page is just data, and I think you are looking to get at that?

I like the idea of %%myst magic.

[tonyfast]

We have officially registered myst as a variant as of last week, and agree that all of the stuff in MyST goes beyond a markup language, and brings a lot of application logic that isn't appropriate everywhere.

nice. that's good diligence.

and I think you are looking to get at that?

yea, the data will be good, but i'd prefer that data in the widely deployed notebook format. i want to give presentations that collage it with other code and media. i am not particular about how things are serialized. i do expect a canonical string representation which is the text/markdown or text/html then i'm happy shipping around any ast or schema yous provide.

[rowanc1]

@agoose77 I think that this is how you have restructured the codebase in the JLab-v4 release?

For example the MySTWidget here: https://github.com/executablebooks/jupyterlab-myst/blob/main/src/widget.tsx#L98