Add support for rendering admonitions using "markdown friendly" syntax
See original GitHub issuei.e. implement an extension in markdown-it-py to encapsulate something like pandoc fenced divs
:::{note}
my note
:::
or suggested in jupyter https://github.com/jupyter/notebook/issues/1292#issuecomment-477152896
!!! note
This is a note.
Then render it here
Issue Analytics
- State:
- Created 3 years ago
- Comments:14 (14 by maintainers)
Top Results From Across the Web
Syntax Extensions - MyST-Parser
Their goal is generally to add more Markdown friendly syntaxes; often enabling and rendering ... This extension is currently only supported for HTML...
Read more >Special content blocks - Jupyter Book
Notes, warnings, and other admonitions# · Blocks of text with custom titles# · Markdown-friendly directives with ::: # · Insert code cell outputs...
Read more >Admonitions - Docusaurus
In addition to the basic Markdown syntax, we have a special admonitions syntax by wrapping text with a set of 3 colons, followed...
Read more >More Authoring - PyCharm Guide - JetBrains
This is the reason for the triple-colon syntax: to allow the directive body in Markdown to render in smart tooling. Lots going on...
Read more >Getting Started | Markdown Guide
Markdown is a lightweight markup language that you can use to add formatting elements to plaintext text documents. Created by John Gruber in...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Another quick thought here as I was playing around with writing this kind of syntax. If we support
:::
, then we probably don’t need the{curly-brackets}
in that case. E.g. treat:equivalent to
since we are not over-riding any other behavior with it.
I think other than that difference, the two patterns should behave exactly the same way. E.g. you could do
and
The one downside I can see there is that there isn’t an obvious separation between the directive name and its arguments
Yep the same way that #132 and #153 will be optionally activated, by making this more configurable: https://github.com/executablebooks/MyST-Parser/blob/8dda2f73364853cb572a50c53434c385db266d7c/myst_parser/main.py#L31-L45