This workbench service handles opening external uris. Unlike the core OpenerService, it also has logic for configuring a default opener and prompting if multiple openers are availble for a given uri
* WIP -Getting Started Registry
* Initial idea of how registry/service will work
* Getting started with Getting Started
* Add telemetry and touch up enablement flag
* Add contrib as startup editor
* Move to allowing static Getting Start blob
* No newline
* Remove unused enum
* chore: bump electron@9.0.5
* remove exploration config
* fix compile error
* fix compile error
* crashReporter has to be called only once before app ready
* chore: bump electron@9.1.0
* enable LayoutNG
* fix cron schedule
* allow disabling appcenter crash reporting
* set additional crash reporting parameters
* start crashreporter for child process on linux
* setup crash parameters only once
* remove unused crashReporter.guid
* address review feedback
* reuse argv.json for storing crash reporter id
* remove trailing commas
* update localized name
* update argv based on telemetry optout
* update initial config based on setting
* fix conditional errors
* remove telemetry.enableCrashReporter
* move default crash reporter config to electron-main
* update comment for ext host crash reporting
* set default value for configuration
* some 💄 changes
* address review feedback
* do not use ES7 features in JS yet
* add app.focus({ steal: true }) usage
Co-authored-by: Benjamin Pasero <benjpas@microsoft.com>
For #82718Fixes#52846
This adds a newly proposed codeActions contribution point. For details, see #82718
This change also makes the intellisense for the `editor.codeActionsOnSave` property dynamic by using the new contribution point
* 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
