jupyterlab-myst icon indicating copy to clipboard operation
jupyterlab-myst copied to clipboard

Consider how users can extend roles/directives

Open agoose77 opened this issue 3 years ago • 11 comments
trafficstars

Context

If a user wants to add a custom role or directive, I think they would need to inject these definitions into the list of roles / directives that the markdown-it-docutils plugin accepts in the options argument. This may not be very easy - the options can be modified from JupyterLab, but to pass in JS objects would require some extension to set these options.

Proposal

Perhaps it would be better to expose a token from jupyterlab-myst that lets users write extensions to provide their own roles / directives. These extensions could be authored using https://github.com/jupyterlab/jupyterlab-plugin-playground to make it easy to play around with them from JupyterLab.

Tasks and updates

No response

agoose77 avatar Jun 12 '22 12:06 agoose77

In jupyter book (well really docutils I guess) you can use a directive to define a custom role. I wonder if that could be supported and also maybe a simple way to define a custom directive, e.g.

```{directive} myname(nameofbase)
:class: adefaultclass
```

I'm not sure what else might be doable beyond setting key-value parameters but that would already be useful.

Of course this concept leads to repetition of boilerplate in markdown files and then you need an include system... so I dunno. It sounds like you have other approaches in mind, and it will be interesting to see what happens.

tavin avatar Feb 28 '23 22:02 tavin

Hello!

Reviving this thread.

I would like to use custom roles to use semantic markup rather than presentation markup in my course notes. E.g. in definitions write:

A {definiendum}`function` is ... 

rather than

A *function* is ...

And have the role generate appropriate presentation. This is a common pattern for e.g. people coming from the latex world.

I have this up and running in my Jupyter book with custom roles, but these roles don't render yet in the notebooks themselves which the students are going to manipulate; this is a show stopper.

Do you have a timeline for custom roles in jupyterlab-myst? I would love to be able to use them for the next semester starting in early September.

A first approximation that would be good enough in a first step is if

{myrole}`foo <bar>`

would be rendered as foo.

Having an analog of latex's newcommand for the simple cases, as alluded to above, would be a very nice second step.

Happy to beta test anything!

Thanks a lot in advance! Nicolas

More context and motivation

The Kwarc group at Erlangen is developing cool online technology so that, if you add some semantic information to your course notes (e.g. this is a definition, this is the concept being defined; these are the concepts that it depends on), then automatically you get a web interface with flash cards, guided tours, all generated automatically and taylored to the learner's current competencies, thanks to learning analytics / learner models.

At this stage, the technology works for course notes written in LaTeX. We are currently experimenting bringing this technology to Jupyter which would be very cool.

nthiery avatar Jun 01 '23 15:06 nthiery

Thanks @nthiery! Excited to get to extensibility, I think it might be possible to get to a beta version of this over the summer as it is coming up much higher on the list in a bunch of places.

Right now unknown roles do render as text: {definiendum}`function` --> function, I think you are also asking for a default of removing the angle-bracket content if it exists? For example: {myrole}`foo <bar>` --> foo. Is that correct?

I think that is probably a sensible default for any unknown roles (maybe with some improved styling as well), and we could do that really fast.

From the extensibility side, things are getting better, from a code perspective the effort involved is:

  • Create a role: https://github.com/executablebooks/mystjs/blob/main/packages/myst-roles/src/smallcaps.ts
  • Add a renderer: https://github.com/executablebooks/myst-theme/blob/ddf09f5ed5deba04d732aaed4246448d35ef0405/packages/myst-to-react/src/basic.tsx#L94
  • Add renderers here: https://github.com/executablebooks/jupyterlab-myst/blob/29de3e79cce06290621f66bbbc79210c3fbcc926/src/renderers.tsx#L8
  • Add roles here: https://github.com/executablebooks/jupyterlab-myst/blob/29de3e79cce06290621f66bbbc79210c3fbcc926/src/myst.ts#L45

We then need some mechanism to extend jupyterlab-myst, e.g. using a new Jupyter plugin (I think?). @tavin has done something similar to this in #115, and that might be a pattern to use? I think @agoose77 also has some thoughts on how to do this.

Right now @agoose77 is putting a bunch of work into making things compatible with JupyterLab 4.0, which has changed a lot with regard to how we are structuring the extension. Our plan after that was to focus on citations/bibliography, but probably things will have settled down at an architecture level to maybe tackle both of these at once -- especially if @tavin's approach is possible, or @agoose77 has some thoughts/ideas/time! Curious on both of your thoughts there!

@nthiery, let me know if a quick improvement to the rendering of unknown roles would be helpful, and we can get that done right away.

rowanc1 avatar Jun 01 '23 16:06 rowanc1

Thank @rowanc1 for the quick feedback! Yes, a quick improvement to the rendering of unknown roles would definitely be helpful.

Will read in detail your post later today; sounds exciting. And indeed I can see that jupyterlab 4 be a priority :-)

nthiery avatar Jun 02 '23 05:06 nthiery

#115 needs to be partially reworked now that #102 has been merged.

Perhaps @rowanc1 or @agoose77 can weigh in on whether it's worth spending time on this?

It would make it easy to distribute a labextension that renders custom roles/directives implemented in ecmascript. You could experiment with custom roles/directives written in myst inside such a labextension.

tavin avatar Jun 13 '23 22:06 tavin

I think there are some major changes coming in #142, and any changes should be based on that. I believe that @agoose77 also has some other restructuring in mind that he wants to do before that PR merges. Currently it is closer to #102 in how it works across everything.

Supporting JupyterLab 4.0 required quite a few changes to the way the whole extension works, but hopefully we are getting to a slightly better pattern. Thanks both for your patience as we sort this out. :)

rowanc1 avatar Jun 13 '23 23:06 rowanc1