Hi everyone! I’d like to brainstorm with the broader community the possibility of extending the notebook format.
tl;dr: should we allow notebooks to be written in markup languages other than markdown?
Markup in notebooks right now
Notebooks have an associated kernel, that allows to interpret the code stored in the notebook. This is a great feature that makes notebooks valuable across many different communities and fulfill many purposes. The kernel may also specify additional language information (e.g. minor versions).
At the same time, all notebook rely on a custom dialect of markdown to provide the textual part.
What’s worse, classic notebook and jupyterlab aren’t using 100% the same markdown specs.[citation needed]
In an effort to standardize the format, @jasongrout started a discussion jupyter/nbformat#80 some time ago.
I would like to discuss an alternative to cementing the spec, namely specifying the “markup kernel” in a notebook. That way just like a jupyter notebook can run code implemented in multiple languages, it would be able to render text written in different markup. This would allow to use jupyter notebooks in more contexts. I think it makes sense because markdown isn’t yet the lingua franca of markup languages: at least asciidoc, ReST, Wikitext, orgmode aren’t going away anytime soon.
There is a family of tools integrating different aspects of jupyter notebook with text files (jupytext being my personal favorite). The impact of those tools would be enhanced if jupyter would also be able to interpret the markup. Take Jupytext: it allows to edit R scripts in the notebook. But R has its own markdown, and their spec isn’t going to be fully compatible with that of jupyter (or not anytime soon). If jupyterlab/classic notebook could instead render different dialects of markdown, the experience would be seamless.
Practical aspects
I imagine the implementation could go in the following way:
- There would be a new notebook metadata entry
markup. Similarly to the kernel information, it’d specify both the overall markup syntax (markdown/rest/…) and the dialect/extensions, similar to how the kernel information contains both the language (Python) as well as the specific version (3.7.3). - The tools that are supposed to work with notebooks would communicate with the “language kernel” for rendering the markup. Pandoc could provide quite a bit of mileage there. One could also imagine using fallbacks (if R markdown parser isn’t installed, a generic markdown would be used).
- Cells which render text would have a cell type
text, as opposed to currentmarkdown.
I would love to hear what everybody thinks about this.