Consider using pandoc markdown for "div"s and RMarkdown for code cells in Jupytext markdown

In using Jupytext, I’ve found that I’d love to have a combination of two features from two different markup languages supported by jupytext:

Pandoc div fences for markdown cells

I often want to tag-up my markdown with metadata that is cell-specific, which means that I need to be able to separate out my markdown chunks into multiple cells. Right now in Jupytext, the way to do this is to write <!-- md --> and <!-- endmd -->. This isn’t bad, but it is a bit cumbersome. I find it much more streamlined to use the Pandoc syntax for divs, such as:

:::md
:::

as opposed to

<!-- #md -->
<!-- #endmd -->

This could be extended to other types as well, e.g.:

:::raw
:::

What do you think about supporting syntax such as this for Jupytext markdown?

RMarkdown code blocks in markdown cells

Another feature I love about RMarkdown is the ability to distinguish “regular” code blocks (using python) from "runnable" code blocks (using {python}). This could be a nice way to separate out the same behavior in Jupytext markdown.

I’m curious what others think about incorporating these into the base flavor of Jupytext md (In addition to manually specifying with comments).

[mwouts]

It has been some time since we last discussed this…

• Indeed people can use Rmd if they want to distinguish between runnable and non-runnable code cells
• I have added the ~~~python trick to the documentation to make non-runnable code cells in the markdown format
• I am not sure I would invite non R users to use the Rmd format, because the code cell metadata have to be coded in R
• More generally, I have the intuition that these kind of questions will be adressed with the myst format (#447)… do you mind if we continue the conversation there?

[mwouts]

Hello @choldgraf , I agree that pandoc div are easier to type, and nicer to read in a text editor. But… they don’t look nice yet in GitHub or in VS code… that was the reason why we did’nt took them. That said, sure, why not allowing them in addition to the other cell markers, as you suggest? I’ll think about that.

The same remark holds for the RMarkdown code blocks: I don’t think that ```{python} blocks are well rendered on GitHub… But I agree with you that having a simple way to distinguish between executable and non-executable cells is necessary.