* Prototype Allowing Extensions to Extend the Builtin Markdown Extension
**Problem**
There have been requests for adding new functionality to the markdown extension preview, such as supporting rendering of math or other syntax in the preview. The only current solution to this is create an extension that provides its own markdown preview. This results in inconsitent behavior with our markdown preview and is not a very scalable approach. We would like to find a way to allow users to add these extensions to our markdown preview without bundling the extensions in the preview itself.
**Fix**
Prototypes a new contribution point that extensions can use to extend the vscode markdown extension. Three types of extensions are possible: adding stypes to the preview, adding scripts to the preview, and extending the markdown it renderer.
My current approach defines the contributed markdown extensions in the package.json using a structure like this:
```
"contributesTo": {
"vscode.markdown": {
"plugins": [
"./out/math"
],
"scripts": [],
"styles": [
"./media/math.css"
]
}
}
```
We could change the structure here. This design uses a pull model where markdown extensions are looked up by the vscode.markdown extension itself.
The other approach for extension registration would be to use a push model. This would have the vscode.markdown extension export an api that each markdown extension would invoke to register new scripts/styles/plugins. I may switch over to this model but was interested in seeing what a more declarative approach would look like. Let me know if you have any thoughts one way or the other.
The downside of allowing extensions like this is that they can completely change how the markdown preview looks and works. There is no well defined API for restricting what extensions can do like we have with VScode.
* Use extensionDependencies
* Remove example extension
* Added gating and activation event
Fixes#22494
**Bug**
References without a definition can cause the markdown table of contents provider to break
**Fix**
Pass in an empty environment to markdown-it `parse` to prevent the null dereference on invalid links.
**Bug**
The markdown grammar for fenced code blocks is rather unmaintainable since it involves lots of copy and pasted code
**Fix**
Use a gulp task and a template to generate the fenced code block grammars include directly. This allows adding new language support much more easily.
Adds enhanced security settings for the markdown preview. The new flow disable all scripts within the preview itself. Users can enable scripts on a per workspace basis.
When a markdown document that uses scripts is loaded, a warning is shown inside the document itself. This warning triggers a new security selector quick pick which allows users to enable or disable enahanced security in the workspace.
Fixes#7776
**Bug**
Code blocks in the markdown preview are not very good looking
**Fix**
Use default text color for indented code blocks and add a background
Fixes#20070
**Bug**
Markdown scroll sync and other sync features do not work for untitled files. The root cause seems to be that the `main.js` markdown file is never loaded
**Fix**
Instead of a using a path without a scheme for `main.js`, use a `file://` path
**Bug**
Scroll sync not working for some users on windows
**Fix**
Root cause seems to be that windows drive/path cases can sometimes differ between preview and editor document. Adds a equality check based on `fsPath` as well
**Bug**
For long/not-terminated frontmatter in a markdown file, we can currently hang the process while trying match it using a regular expression
**Fix**
Use a more efficent regexp to do this.
* Remove unneeded d.ts files from extensions
Moves most extensions to use the lib files for the standard library that typescript provides.
* Remove a few more node.d.ts references