mirror of
https://github.com/Microsoft/vscode
synced 2024-11-05 18:29:38 +00:00
011836a150
* Custom Editor exploration For #77131 Adds a prototype of custom editors contributed by extensions. This change does the following: - Introduces a new contribution point for the declarative parts of a custom editor - Adds API for registering a webview editor provider. This lets VS Code decided when to create a webview editor - Adds an `openWith` command that lets you select which editor to use to open a resource from the file explorer - Adds a setting that lets you say that you always want to use a custom editor for a given file extension - Hooks up auto opening of a custom editor when opening a file from quick open or explorer - Adds a new extension that contributes a custom image preview for png and jpg files Still needs a lot of UX work and testing. We are also going to explore a more generic "open handler" based approach for supporting custom editors Revert * Re-use existing custom editor if one is already open * Don't re-create custom editor webview when clicking on already visible custom editor * Move customEditorInput to own file * First draft of serializing custom editor inputs * Use glob patterns instead of simple file extensions for matching custom resoruces for custom editors * Add descriptions * Try opening standard editor while prompting for custom editor * Make sure we hide image status on dispose * Make sure we restore editor group too * Use glob patterns for workbench.editor.custom * Allow users to configure custom editors for additional file types * Use filename glob instead of glob on full resource path * Adding placeholder for prompt open with * Add enableByDefault setting for editor contributions * Enable custom editors by default and add `discretion` enum Changes `enableByDefault` boolean to a `discretion` enum. This should give more flexibility if we want other options (such as forcing a given custom editor to always be used even if there are other default ones) * Allow custom editors to specify both a scheme and filenamePattern they are active for * Rework custom editor setting * Don't allow custom editors to be enabled for all resources by a config mistake * Replace built-in image editor with one from extension * Adding reopen with command * Improve comment * Remove commented code * Localize package.json and remove image * Remove extra lib setting from tsconfig |
||
|---|---|---|
| .. | ||
| jsdoc.injection.tmLanguage.json | ||
| Readme.md | ||
| TypeScript.tmLanguage.json | ||
| TypeScriptReact.tmLanguage.json | ||
The file TypeScript.tmLanguage.json and TypeScriptReact.tmLanguage.json are derived from TypeScript.tmLanguage and TypeScriptReact.tmLanguage.
To update to the latest version:
cd extensions/typescriptand runnpm run update-grammars- don't forget to run the integration tests at
./scripts/test-integration.sh
Migration notes and todos:
-
differentiate variable and function declarations from references
- I suggest we use a new scope segment 'function-call' to signal a function reference, and 'definition' to the declaration. An alternative is to use 'support.function' everywhere.
- I suggest we use a new scope segment 'definition' to the variable declarations. Haven't yet found a scope for references that other grammars use.
-
rename scope to return.type to return-type, which is already used in other grammars
-
rename entity.name.class to entity.name.type.class which is used in all other grammars I've seen
-
do we really want to have the list of all the 'library' types (Math, Dom...). It adds a lot of size to the grammar, lots of special rules and is not really correct as it depends on the JavaScript runtime which types are present.