Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider how users can extend roles/directives #45

Open
agoose77 opened this issue Jun 12, 2022 · 6 comments
Open

Consider how users can extend roles/directives #45

agoose77 opened this issue Jun 12, 2022 · 6 comments
Labels
enhancement New feature or request

Comments

@agoose77
Copy link
Collaborator

agoose77 commented Jun 12, 2022

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 agoose77 added the enhancement New feature or request label Jun 12, 2022
@tavin
Copy link
Contributor

tavin commented Feb 28, 2023

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.

@nthiery
Copy link

nthiery commented Jun 1, 2023

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.

@rowanc1
Copy link
Member

rowanc1 commented Jun 1, 2023

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:

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.

@nthiery
Copy link

nthiery commented Jun 2, 2023

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 :-)

@tavin
Copy link
Contributor

tavin commented Jun 13, 2023

#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.

@rowanc1
Copy link
Member

rowanc1 commented Jun 13, 2023

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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants