* fonts - adopt monaco-monospace-font in more places and make it consistent
* font - use platform specific fonts in more places
* font - move system-ui before Ubuntu font in places where we cannot control platform
* font - only use system-ui on Linux
* fonts - adjust font stack for other windows
This change primarly adds a new `Open with...` entry to the explorer context menu. To do this however, I had to make a few other changes:
- Add a new explorer context key for availible editors
- Moved the editor select prompt into a new function called `openEditorWith`
- Use `openEditorWith` for the new `open with` explorer command as well as for the `reopen with` command
Splits the preview part of the markdown preview from the dynamic preview management part of things. Static preview swap to preview the active markdown file and don't scroll sync with any other markdown files
For #77131Fixes#93963Fixes#94515Fixes#94517Fixes#94527Fixes#94509Fixes#94514Fixes#93996Fixes#93913
This removes explicit edits from the API and reshapes the API to more closely match VS Code's internal API. The change also tries to better express the lifecycle of backups
For #77131
- Use a class for `CustomDocument` instead of an interface. Extensions can now add their own data to a `CustomDocument` by sublassing
- Renamed `resolveCustomDocument` to `openCustomDocument` and require that extensions return a `CustomDocument`
- Exposed edits on `CustomDocument`
- Made the third parameter of `registerCustomEditorProvider` a generic options bag that takes a `webviewOptions`
For #77131
Going back the the delegate based model for a few reasons:
- It gives us a better approach to add additional API hooks in the future (such as for rename)
- In practive, the capabilities were almost always the same as the `userData` on the document. It is rather confusing to have both `userData` and the capabilities 'on' the document
For #77131
**Motivation**
While our existing webview editor API proposal more or less works, building an editable webview editor is fairly tricky using it! This is especially true for simple text based editors.
It'd also be nice if we could get bi-directional live editing for text files. For example, if I open the same file in a webview editor and in VS Code's normal editor, edits on either side should be reflected in the other. While this can sort of be implemented using the existing API, it has some big limitations
**Overview of changes**
To address these problems, we've decided have two types of webview editors:
- Text based webview editors. These editors used a `TextDocument` as their data model, which considerably simplifies implementing an editable webview. In almost all cases, this should be what you use for text files
- Complex webview editors. This is basically the existing proposed API. This gives extension hooks into all the VS Code events, such as `save`, `undo`, and so on. These should be used for binary files or in very complex text editor cases.
Both editor types now have an explicit model layer based on documents. Text editor use `TextDocument` for this, while custom editors use `WebviewEditorCustomDocument`. This replaces the delegate based approach previously used.
**Problem**
All of our extensions currently are built using the dom typings. This can lead to runtime errors if you mistakenly use `window` or similar
**Fix**
Exclude the dom typings from compile. Then explicitly import the node types for `URL` and `TextEncoder`
* Fix#82199
This PR resets color theme of number, title and built_in at Preview with light theme.
* Bad whitespace indentation Fixe
* owner comment Removed
Fixes#80680
- Always sync the current preview line number with the editor, even when `scrollEditorWithPreview` is false
- If the md file is focused and refresh is called, do not try resetting the current line to match the editor file. This mainly effects the case where `scrollEditorWithPreview` is false
* Fix bug causing a large number of linters to be activated due to the markdown extension opening TextDocuments during indexing
* indentation problem
* code review by @OmarTawfik
* revert changed file
* Code review: use nodejs' Buffer
* fix ineffcient code
code review comments
* introduce SkinnyTextLine
* refactor redundant code
* revert changed files
* formatting
* remove empty line
* Fix for #26659.
Clicking on a local file link will open up the editor on a separate editor group (new or reuse existing one).
* Fix for #26659: Add way to open Markdown links in a different editor group
Adding "markdown.editor.openMarkdownLinks" setting to specify where
links to markdown files should open (current editor group by default).
Sets the tab size to 4 in the Markdown preview for code blocks in Markdown documents. I consider a tab size of 4 being standard and the default of 8 being unbearable. The few people, if any, using a different tab size than 4 can use the custom markdown preview style feature, if it is going to be fixed anytime (https://github.com/microsoft/vscode/issues/77290).
[`tab-size` is still marked *experimental* in the MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size), but it doesn't hurt, if not supported. However, in the used Chromium version it is supported.
This adds a command which renders the provided document, or the active
editor if one is provided. Following the pattern of some of the preview
commands, it returned `undefined` if there's no document provided and
no active text editor. Otherwise, seems to work...
```ts
const html = await vscode.commands.executeCommand<string>('markdown.render');
```
A way to render arbitrary strings in addition to documents may be useful at
some point in the future. However, I didn't implement that here as that'd
require some refactoring of the markdown engine. If we're interested though
I could certainly give that a shot.
Fixes#72155
Adds a constant to the api that tracks the root path for resources inside of webviews. This is required because we will not be able to use `vscode-resource:` uris on the web. Our current approach is to rewrite the html we are given but there are almost certainly going to be cases where we don't get this quite right.
Adopts the new api for the markdown preview
* upstream/master: (34 commits)
Fix markdown.styled regression caused by Uri.parse changes
Process explorer refactoring
fix compile error
fix open workspace uri from cli
Delete deprecated search provider stub
test dependenices are devDependencies
Fix default uri when scheme is file
disable flaky test, #71801
use `readonly T[]` instead of `ReadonlyArray<T>`
simplify protocol check
Let enablment service handles local workspace extensions in remote window
debt - make ext host init data more complete
Fix colorization tests
fixes#71671
Update grammars
Add yes-no choice for overwriting existing file for save as
update distro
ExtensionEnablementService: - Remove getDisabledExtensions and instead use isEnabled or getEnablementState methods
Simplify reload action and fix test
Update distro hash
...
