I think the important two questions to ask are I agree with your assessment that the biggest challenge is just agreeing on something and going with it (this is the same problem that the CommonMark community has). It may look simple to “just” capture what is in between ). (and let’s not dive into ‘now markdown cells are security concern’ side of things as well, and impact the “trust” status of a notebook, but it’s quite an important one.) You’ll get questions on how to display graphs and multiline contents, like df.head().You’ll end up having out of sync values with what is in the kernel, and might want to start having a prompt number to debug.You’ll end up capturing all outputs mimetype (hey what is in a cell output).Technically you want to use the user_expressions – not the typical code execution flow – field of the Jupyter protocol as well, and either make sure you supress all those (which I would discourage as otherwise you’ll get plenty of hard to debug error messages), special case it, or heavily modify the frontend so the markdown cells get many of the same features code cells have: It’s a bit more complicated as now your markdown may have to deal with side effects, like exception, print statement and so on. You mean exactly like I tried to do about 8 years ago ? Is there a reason that you’d need to have kernel-specific information to handle that, in a different way from a code cell?

IMHO the “use magics” approach is the least backward incompatible (it will work on old frontend, except the code will still show), and fastest to implement – basically just a hide/show in frontend, no changes in nbconvert and co, and let different approaches to include this in markdown compete. Like in R, $ are valid, not in Python curly brackets will Likely be a problem as delimiters in in C/C++ or rust kernel.Īs soon as you will want “some” makdown/kernel integration you will have to have custom code in your kernel anyway.Īnd the problem with trying to standardise it in Jupyter and say ‘this is the jupyter markdown specification’ is that we tried it a couple years ago and gave up because even the common-mark folks gave up.Īlso the flip side of “all the kernels needs to implement it” is “all the frontends needs to implement it”, which is not easier.

Plus I’m strongly expecting the logic to anyway have to depend on the kernel language and the type of expression you will/can allow depends on your language. It’s not more logic than if you need to add specific handling of “markdown cell execution”.

Rmarkdown vscode