Change:
"@iktakahiro/markdown-it-katex@https://github.com/mjbvz/markdown-it-katex.git": version "4.0.1" <del> resolved "https://github.com/mjbvz/markdown-it-katex.git#b1ed14de467031f5d4f9c1588dd1868cab0b8744" </del> <ins> resolved "https://github.com/mjbvz/markdown-it-katex.git#2e3736e4b916ee64ed92ebfabeaa94643612665a" </ins> dependencies: katex "^0.13.0"

Discussion:
<div type='discussions-op-text'<supOriginally posted by jhconning April 7, 2022</supThe Quarto notebook project builds part of its documentation around how to use vs-code with the jupyter extension to create beautifully rendered HTML and pdf documents However, I've noticed a problem with using Quarto syntax that results in a katex parsing error in a markdown cell when using the juptyer extension. The issue does not arise using JupyterLab. Quarto allows one to label and cross-reference equations, as described here: In the example there, a label is immediately after the delimiter (does not work if the label is on the next line). The rendered quarto document then produces a numbered equation and the label can be used elsewhere in the document to create clickable cross-reference links. The problem is that the juptyer extension in vs-code chokes on this syntax, and presents a Katex parser error instead of the rendered cell: <img width="701" alt="image" src="https://user-"This problem does not arise in Jupyterlab, where the same is rendered like this: <img width="401" alt="image" src="https://user-"Would it be possible to change the parsing to allow this syntax? One could then develop notebooks using the jupyter extension and also have the option of using the powerful extra directives and syntax from quarto to produce beautiful websites, books, blog posts, and other documents.</div
Looks like the parser doesn't like the trailing . Based on the screen shot it looks like Jupyter just ignores this text Here's the relevant code to look into fixing this:
Jupyter can easily make it because its Markdown parsing is powered by Marked, as I noted in Marked is not CommonMark-compliant. Indeed, they disagree at the very first step of parsing (block-level): , I'd recommend just replicating Jupyter's Marked for processing Markdown in a Jupyter notebook. This could potentially solve half of the problems occurring in rendering Jupyter Markdown by .
Since Jupyter does not allow blank line inside an equation, there is still a chance of mimicking its logic in a plugin: Only contribute inline rules. In other words, all math areas must be treated as inline structures at Markdown level. This is not a rare choice, but against the design of . From this perspective, I recommend building a separate dedicated plugin.

Or you can choose to make mostly incompatible with the original one. now defines several inline and leaf block structures. So, the first thing is to merge them into one inline rule. What about simply naming it "", or verbosely ""? Anyway, this step is complicated. The remaining work is just adjusting rendering calls (renderer rule). We can distinguish structures by  as long as it's properly set during parsing.
I'd like to take a stab at this - not completely sure where to start though, would appreciate some hints or leads!
The relevant plugin is here: Once you fix the issue in the repo — which includes tests you can use to verify the fix — we can then pick up the fix in VS Code
Thanks for the help. The approach I'm currently taking involves changing this line here: Am I going down the right path, or is there something else I should try?
pushed a code fix to my fork - the code no longer only checks the last two characters for the terminating double dollar sign. Let me know if this is looking good so far.
Can yon please try creating a PR for this so I can more easily review it? Also be sure to add some tests to confirm the new behavior