Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.62.2 OS Version: Windows 8.1 Steps to Reproduce: a markdown file with the following content: Open a Preview to the side Rendering/Parsing of line 5 goes wrong Parsing of line 6 gives the: I have line 3 and 4 to determine what causes the problem, it is the literal text at the end of line 5: Any literal text (single backtick) of the content: generates the error If there is a tag on a line, any literal text (single backtick) after that is not recognized by the syntax highlighting in the editor
I have just updated the extension that has this piece of Markdown in the README. Github, Marketplace and Extension Bar all render the markdown correct.
I recommend that you disable the built-in , because it turns the Markdown inside VS Code to a flavor much different from GFM that you apparently don't want. The Markdown Math was introduced in . Besides, if you install some VS Code extensions that offer math support someday, you will need to check their documentation to disable the corresponding features. The rendering did not go wrong, to my knowledge. You just discovered the dark side of Markdown. Markdown is not a single rigorous language, but a collection of various flavors (aka "dialect", "variant") that disagree with each other. Let's take a glance at its history first, though there should already be more detailed articles on the Internet. created in 2004. It's the origin of Markdown, and unfortunately ambiguous. Soon, flavors bloomed. Many years later, a group led by began to develop . The new spec has become the basis of many flavors in recent years. Among these derivatives, the current , , is the one that you're familiar with. Interestingly, a number of Markdown implementations adopt GFM and modify its extensions to create new flavors, for example, . I don't know the very flavor that VS Code's Markdown Math tries to follow, but it ( and . Please correct me. Now we can see that lots of Markdown flavors are technically incompatible. Thus, it's a pity that Markdown users have to configure their processors to get desired results. Here, in VS Code, the built-in ships a GFM-like environment. You can to get a more GFM-like experience as long as you're careful.
Minimal example that demonstrates the issue:
Marking as a good first issue since this should be a fairly scoped bug Here's the relevant repository where this issue should be fixed: The repo includes tests that you can use to confirm the issue is fixed and also check for regressions
I am looking to fix this by not allowing a dangling dollar symbol inside a markdown block to open or close. Do you think I'm on the right path?
I still do not regard the behavior here as a bug. Things just work this way as per the inline parsing strategy of CommonMark. From a CommonMark-compliant parser's view, we can say in a non-normative way that is equivalent to Then, given the enabled rules ( default, CommonMark HTML, pandoc-style math, and something else), it's recognized as This is correct and exactly reflects the philosophy of CommonMark. This issue ought to be marked as flavors are not compatible, . A derivative flavor can inherit the philosophy of its parent, but cannot retain the semantics. In other words, you cannot enable a math plugin and expect GFM-like rendering at the same time. You can only discuss right or wrong within the same flavor. If you want GFM-like rendering, disable the built-in Markdown Math () extension first.
But how do I write in Markdown Math a line that shows me Is there a way to Escape the
Avoid plain HTML-like pieces in Markdown. Use proper syntax whenever possible. In Markdown, HTML-like pieces (leaf block "HTML block" and inline structure "Raw HTML") are nothing, but just a kind of literal content. CommonMark requires implementations to skip them: There are roughly 7 + 6 rules for recognizing HTML-like pieces; HTML-like pieces are captured, and then emitted as-is to the output, without further touching parser's machine state. This design is a compromise for compatibility, and causes usability and security issues, like your cases. jgm complained about the terrible fact many years ago. As for escaping, if your use case is presenting a character in textual content, you can try "backslash escape" like , and "entity and character reference" like and .
Maybe the wrong example asked, the OP was about some italic (or bold) text inside a code block, it was done with <codefoo<embar</emfoo</codeand when you use a character outside backticks and further down on the line a it goes wrong. I did not know Markdown allowed HTML entities. I have now enabled Markdown Math and replaced all characters inside with and now there is no
Excuse me? I'm confused now. So, you add these dangerous pieces to your Markdown document for formatting? Unfortunately, CommonMark Markdown is not a superset of WHATWG HTML. They actually have almost no intersection, and apply nearly opposite handling when encountering pieces that look like HTML tags. If you decide to have HTML-like things in a Markdown document, you have to be careful, and know how to lead the parser to your desired result. I thought I've made these basic facts clear. But seems no. No one understands my comments above. Before I come up with another way to explain, we can demonstrate something by this sample: If it's treated as HTML, there is one element with a comment and a text node "" inside. However, if you feed it to a CommonMark-compliant renderer, you'll get somewhat illegal HTML output:
If they are so dangerous why do they allow HTML tags in CommonMark Markdown? As soon as you use single or triple backtick all inside is treated as literal, there is AFAIK no way to make something inside italic (or bold) using Markdown syntax. I use HTML tags to get the required rendered output.
Good to know. Then, you only need to be careful when configuring Markdown renderer and authoring Markdown documents. This is for not only performance but also conformance. Avoid using inappropriate parsers, as flavors may hold dramatically different logic. For example, , , and can give mostly different results for the same input. The Markdown flavor of GitHub is GFM. GitHub processes user content with , and then pipes the HTML output through some "filters" to add GitHub-specific features, such as sanitization, heading anchors, emoji codes, issue references, and diagrams. , VS Code's provides default + , which is a few steps away from GitHub. Basically, you just need to install extensions for emoji and task list, and disable those that don't exist on GitHub (e.g. ). Additionally, since VS Code and GitHub generate heading ID with slightly different methods, a link to heading might work on one and break on the other. It's John Gruber, , that introduced "HTML" (but not real HTML). The world has no choice but to live with it. If you ask me to judge Gruber's decision, I'd say the "HTML" in Markdown is a sign of laziness, besides, thousands of collective developer hours have been wasted due to tons of lazy and ambiguous design of the original Markdown. He should have defined generic construct syntax first, and built language structures on top of it. Probably I'm bad at teaching. But other people have good skill in communication. I recommend their articles:

Discussion:
"@iktakahiro/markdown-it-katex@mjbvz/markdown-it-katex": version "4.0.3" <del> resolved "https://codeload.github.com/mjbvz/markdown-it-katex/tar.gz/17509eaeb7d48887d62ca02eb5eee9e6372b80ac" </del> <ins> resolved "https://codeload.github.com/mjbvz/markdown-it-katex/tar.gz/58f6637b5883caa8a811f1736bc90b34cd26b395" </ins> dependencies: katex "^0.16.2"

integrity sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww== katex@^0.16.2: <del> version "0.16.3" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.3.tgz#29640560b8fa0403e45f3aa20da5fdbb6d2b83a8" integrity sha512-3EykQddareoRmbtNiNEDgl3IGjryyrp2eg/25fHDEnlHymIDi33bptkMv6K4EOC2LZCybLW/ZkEo6Le+EM9pmA== </del> <ins> version "0.16.4" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.4.tgz#87021bc3bbd80586ef715aeb476794cba6a49ad4" integrity sha512-WudRKUj8yyBeVDI4aYMNxhx5Vhh2PjpzQw1GRu/LVGqL4m1AxwD1GcUp0IMbdJaf5zsjtj8ghP0DOQRYhroNkw== </ins> dependencies: commander "^8.0.0"