Add IMarkdownParser interface and markedparser extension.

[AlbertHilb]

This is the implementation of the idea I expressed in #5770.

The Markdown world is definitely moving towards CommonMark: GitHub, Discourse, GitLab have migrated to the new standard (with extensions); VSCode uses CommonMark (via markdown-it); even marked - the renderer used in Jupyterlab - is slowly but steadily embracing it.

Sooner or later also Jupyterlab will have to adopt CommonMark.

At that point the choice of the Markdown renderer will be based on the the parsing speed, on its capacity to be extended or on the ability to create sourcemaps, rather than on the output it produces (since different compliant renderers should virtually produce the same output).

The IMarkdownParser inteface, I think, will make easier to write Jupyterlab Markdown renderers based on different parsers, so that users will able to choose the one they prefer as already happens for the LaTeX renderers.

Cheers

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[fcollonval]

@AlbertHilb would you be interested in rebooting this feature? It makes lots of sense to me and could help as you mention hooking another markdown renderer and it will avoid loading embedding codemirror in smaller extension derived application like gator.

cc @agoose77 as author of jupyterlab-markup could you comment on this one in particular would it simplify jupyterlab-markup?

[agoose77]

@fcollonval I don't think this PR would simplify much for jupyterlab-markup, only because we're currently monkey-patching the call to createRenderer:
https://github.com/agoose77/jupyterlab-markup/blob/9d87112b42a00292841b33224817da0e95f58136/src/manager.ts#L56-L58
This is not because we can't declare a markdown mime-renderer; I think we were just lazy at the time.

The reason JupyterLab has an ILatexTypesetter interface/token (as far as I can tell) is because mathematics rendering is orthogonal to Markdown - for example, we use it in the HTML renderer too.

Some useful changes as I see them:

1. Currently rendermime handles markdown parsing amongst other work. I suspect this was a historical artefact. Instead, I think this should be its own package. It's not hard to replace the Markdown renderer, but whilst we still have the renderMarkdown inside the rendermime package, the boundaries of what is core functionality and what is a plugin are not as well enforced.
2. I also think the ILatexTypesetter interface maybe be moved to its own package. This is not as strong an opinion; maybe its fine to have it inside rendermime, but in a "pure" world, we'd separate the concerns of each package more carefully.

[fcollonval]

Thanks for the quick answer @agoose77 I agree with you that it sounds more generic if those two where in their own packages. This will help simpler remix application to pick only what they want.