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

Compatibility with RST Glossaries #618

Closed
rowanc1 opened this issue Sep 25, 2023 · 3 comments · Fixed by #1223
Closed

Compatibility with RST Glossaries #618

rowanc1 opened this issue Sep 25, 2023 · 3 comments · Fixed by #1223
Labels
bug Something isn't working

Comments

@rowanc1
Copy link
Member

rowanc1 commented Sep 25, 2023

We should add compatibility with Sphinx/RST glossaries (which are based around indentation). At the very least the compatibility warning should be improved with a link to how to do this in Sphinx.

See executablebooks/MyST-NB#544 (comment)

@rowanc1 rowanc1 added the bug Something isn't working label Sep 25, 2023
rowanc1 added a commit that referenced this issue Sep 26, 2023
This now points to RST and gives an example to Sphinx users.

See executablebooks/MyST-NB#544 and #618
rowanc1 added a commit that referenced this issue Sep 26, 2023
This now points to RST and gives an example to Sphinx users.

See executablebooks/MyST-NB#544 and #618
@agoose77
Copy link
Contributor

I suspect there will be more than one instance of places that we want to break Sphinx compatibility for strictness. I wonder whether we should introduce compatibility, but hide it behind a feature flag. The idea would be that jupyter-book could enable this flag, but MyST-md would have no need of it.

Then again, jupyter-book would probably just define a custom high-priority transform that normalises the glossary.

Which of the two do you prefer?

@rowanc1
Copy link
Member Author

rowanc1 commented Mar 19, 2024

Yes, I like doing this via a flag, and having pre-defined configs for different compatibility stories (e.g. sphinx, quarto, etc.).

The was I had played out the development of this is to look at the parsed body content in the directive, if it has definition lists, then it is the new format, if not, parsing that based on the body's raw text in the directive, and calling the parse function after splitting on new lines. The outcome of this directives run function would then always be a defList.

@agoose77
Copy link
Contributor

The was I had played out the development of this is to look at the parsed body content in the directive,

I had the same thought! I like the idea of gating that behind a feature flag so that we can have a "strict" parser for core MyST, but more liberal for JB.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants