gpoore

I've created Codebraid (https://codebraid.org/) for writing in Markdown. It makes inline code and code blocks executable, and includes support for Jupyter kernels. It uses Pandoc internally to parse the Markdown. There's also a VS Code extension that provides a live preview with scroll sync.

For the LaTeX case, I created PythonTeX (https://github.com/gpoore/pythontex) years ago, but haven't done much with it recently.

I actually released my extension around the same time that the Quarto extension came out. Quarto is great for documents running R code or needing some of Quarto's advanced document features. My extension has scroll sync and the preview updates live while you type. If you need code execution, you can use multiple Jupyter kernels per document and execute inline code. Also, code execution is non-blocking, so the preview still updates when you type, and code output appears live as it becomes available.

Yes, I'm adding support for arbitrary text-based formats, including LaTeX. So it will be possible to write LaTeX and see a live HMTL preview generated by Pandoc.

In principle, it should be possible to create a PDF preview with proper SyncTeX support for synchronizing LaTeX source and PDF preview locations, but that gets complicated when Pandoc+LaTeX generate the PDF. It may be best to leave LaTeX-PDF previews to dedicated LaTeX previewers that don't involve Pandoc.

I've been frustrated by Markdown previews not supporting Pandoc features, so I created a Pandoc-based Markdown preview for VS Code [1]. The preview supports all Pandoc extensions to Markdown syntax, because Pandoc itself generates the preview. There is also optional support for code execution with Jupyter kernels. I'm currently in the process of adding support for non-Markdown formats (including scroll sync), plus taking advantage of some of the new Pandoc 3.0 features.

[1]: Examples and animations: https://codebraid.org/presentations/scipy2022/. Installation for VS Code: https://marketplace.visualstudio.com/items?itemName=gpoore.c.... Installation for VSCodium: https://open-vsx.org/extension/gpoore/codebraid-preview.

I've created a VS Code extension that provides a live Pandoc preview with scroll sync and support for executing code: https://marketplace.visualstudio.com/items?itemName=gpoore.c.... Adding support for diagrams would just be a matter of creating a config file specifying the diagram executable and command-line options.

For the Python in markdown case, you might be interested in one of my projects that allows executable Python code (including optional Jupyter kernel support) in Pandoc markdown: https://github.com/gpoore/codebraid. Pandoc does all the document parsing (there is no regex preprocessor for extracting code), so converting markdown to markdown often works particularly well.

Check out matplotlib's PGF backend: https://matplotlib.org/users/pgf.html

I've created https://github.com/gpoore/codebraid for running Python in Pandoc Markdown. It's written in Python and focused on executing Python code, though it also supports Julia, R, Rust, Bash, and JavaScript. It operates on the Pandoc AST, so there are no Markdown preprocessor issues and there's no custom Markdown syntax.

Yes, that's one way to describe what I'm hoping to do with this. The focus right now is on markdown, but since Pandoc supports so many input formats, it should be easy to add support for other formats like LaTeX once the markdown features stabilize. There isn't yet an equivalent of org-babel's ability to share data between code blocks, though I hope to add something similar eventually. The next big feature will probably be the ability to name code blocks, and then insert any combination of their code/output/errors at arbitrary other locations in the document.

I suspect the speed issues are more a result of implementation details than of being in Python. Last year, I created a config language for my own use that supports some syntax very similar to YAML. My pure Python library can load simple dict/list/string data 10x as fast as PyYAML, and nearly within 1.5x the speed of libyaml (https://bespon.org/#benchmarks). That's while building an AST with source information to allow round-tripping and supporting my own version of anchors and tags, so there's significant room for improvement. I expect that a pure Python YAML library might be able to match or beat the current performance of libyaml in at least some cases, particularly for a restricted subset of YAML.