|
|
|
|
@ -23,83 +23,82 @@ We really appreciate people trying our new features as soon as they are ready, s
|
|
|
|
|
|
|
|
|
|
If you find issues or have suggestions, you can enter them in the [VS Code repository](https://github.com/Microsoft/vscode/issues) on GitHub.
|
|
|
|
|
|
|
|
|
|
## Workbench
|
|
|
|
|
|
|
|
|
|
### Screencast mode keyboard indicator timeout
|
|
|
|
|
The new `screencastMode.keyboardOverlayTimeout` settings allows the user to customize the time in milliseconds for the keyboard indicator.
|
|
|
|
|
|
|
|
|
|
### Screencast mode mouse indicator color and size
|
|
|
|
|
The new `screencastMode.mouseIndicatorColor`, and `screencastMode.mouseIndicatorSize` settings allows the use to customize the mouse indicator color and size.
|
|
|
|
|
|
|
|
|
|
## Editor
|
|
|
|
|
|
|
|
|
|
### Only Format Modified Ranges
|
|
|
|
|
### Only format modified text
|
|
|
|
|
|
|
|
|
|
When contributing to another project, "Format on Save" and "Format Document" can get in your way because they format lines that you have not changed. This makes pull requests large and is often unwanted. There is new feature to help with that:
|
|
|
|
|
When contributing to another project, the **Format on Save** and **Format Document** commands can cause unwanted updates because they format lines that you have not changed. This behavior can result in large pull requests, which are hard to review and touch code you didn't intend to modify. There is now a new feature to help limited unwanted changes:
|
|
|
|
|
|
|
|
|
|
* We added a new command "Format Modified Lines" which allows to manually format new and changes lines
|
|
|
|
|
* There is a new setting `editor.formatOnSaveMode` which makes "Format on Save" only format modified lines
|
|
|
|
|
* We added a new command **Format Modified Lines**, which allows you to only format new and changes lines.
|
|
|
|
|
* There is a new setting `editor.formatOnSaveMode`, which makes **Format on Save** only apply to modified lines.
|
|
|
|
|
|
|
|
|
|
Note, that modifications are defined by your source control provider, e.g changes in git, and that without changes in source control no modified lines are formatted. The quick diff indicator is a reliable hint for what lines will be formatted.
|
|
|
|
|
Note that modifications are defined by your source control provider, for example, changes as detected by Git, and that without changes in source control, no modified lines are formatted. The Quick Diff indicator is a reliable hint for what lines will be formatted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This also requires a formatter that supports to format a portion of a document - which popular formatter do.
|
|
|
|
|
This also requires that the active formatter supports to formatting only a portion of a document, which most popular formatters do.
|
|
|
|
|
|
|
|
|
|
### Format Multiple Selections
|
|
|
|
|
### Format multiple selections
|
|
|
|
|
|
|
|
|
|
Also, the "Format Selection" command is now multi-cursor aware. Select multiple lines or statements, trigger "Format Selection", and you are set.
|
|
|
|
|
The **Format Selection** command is now multi-cursor aware. Select multiple lines or statements, trigger **Format Selection**, and formatting will be applied to all sections.
|
|
|
|
|
|
|
|
|
|
### Find cursor move on type
|
|
|
|
|
|
|
|
|
|
### Find widget cursor move on type
|
|
|
|
|
|
|
|
|
|
Previously when you type in the Find Wiget input box, VS Code will automatically search and then move the cursor to the nearest find result. Now you can control if the cursor should jump to the find matches while typing by configuring `editor.find.cursorMoveOnType`. When disabled, VS Code will only move the cursor when you press Enter/Shift+Enter.
|
|
|
|
|
When typing in the Find input box, VS Code automatically searches and moves the cursor to the nearest find result. You can now control if the cursor should jump to the find matches while typing by configuring `editor.find.cursorMoveOnType`. When disabled, VS Code will only move the cursor when you press `Enter/Shift+Enter`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Workbench
|
|
|
|
|
|
|
|
|
|
### Screencast mode keyboard indicator timeout
|
|
|
|
|
|
|
|
|
|
The new `screencastMode.keyboardOverlayTimeout` setting allows you to customize the time in milliseconds for the keyboard indicator.
|
|
|
|
|
|
|
|
|
|
### Screencast mode mouse indicator color and size
|
|
|
|
|
|
|
|
|
|
The new `screencastMode.mouseIndicatorColor` and `screencastMode.mouseIndicatorSize` settings control the mouse indicator color and size.
|
|
|
|
|
|
|
|
|
|
## Debugging
|
|
|
|
|
|
|
|
|
|
### Debug Console Filter
|
|
|
|
|
### Debug Console filter
|
|
|
|
|
|
|
|
|
|
The Debug Console now supports filtering which makes it easier for users to find the output they are looking for or to hide irrelevant logging output. The filter also supports exclude patterns (i.e. patterns starting with an exclamation mark `!`).
|
|
|
|
|
The filter only applies to program output but not to evaluations run by a user. Like other input boxes in VS Code you can use `up` and `down` arrow keys to navigate between old filter inputs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Debug Console now supports filtering, making it easier for users to find the output they are looking for or to hide irrelevant logging output. The filter also supports exclude patterns (for example, patterns starting with an exclamation mark `!`). The filter only applies to program output but not to evaluations run by a user. Like other input boxes in VS Code, you can use the `up` and `down` arrow keys to navigate between old filter inputs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### UX improvements
|
|
|
|
|
* When debugging multiple sessions, we now only render the arrow in the glyph margin for the focussed session. This should make it easier for users to distinguish which editor call stack decoration belongs to the debug session the user is interested in.
|
|
|
|
|
* Large stack frames now show a "Load All Stack Frames" button to load all the remaining stack frames. Previously this was a "Load More Stack Frames" button which would require multiple clicks for very large stack traces.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* When debugging multiple sessions, VS Code now only renders the arrow in the glyph margin for the focused session. This should make it easier for users to distinguish which editor Call Stack decoration belongs to the debug session the user is interested in.
|
|
|
|
|
* Large stack frames now show a **Load All Stack Frames** button to load all the remaining stack frames. Previously this was a **Load More Stack Frames** button, which would require multiple clicks for large stack traces.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### JavaScript Debugger Improvements
|
|
|
|
|
### JavaScript debugger improvements
|
|
|
|
|
|
|
|
|
|
#### Improved Auto-Attach
|
|
|
|
|
**Improved Auto-Attach**
|
|
|
|
|
|
|
|
|
|
[Auto Attach](https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_auto-attach-feature) can now debug processes even without manually passing an `--inspect` flag to them. When auto attach is turned on, by default VS Code uses its "smart" mode to debug any Node.js script outside of `node_modules` folders, as well as some common 'runner' tools such as mocha and ts-node.
|
|
|
|
|
[Auto Attach](https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_auto-attach-feature) can now debug processes even without manually passing an `--inspect` flag to them. When Auto Attach is turned on, by default VS Code uses its "smart" mode to debug any Node.js script outside of `node_modules` folders, as well as some common 'runner' tools such as mocha and ts-node.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*Theme: [Codesong Theme](https://marketplace.visualstudio.com/items?itemName=connor4312.codesong)*
|
|
|
|
|
|
|
|
|
|
You can switch back to the old behavior, or choose to debug _all_ Node.js scripts, using the **debug.javascript.autoAttachFilter** setting. If you want to change when the "smart" mode attaches, you can configure it in the **debug.javascript.autoAttachSmartPattern** setting.
|
|
|
|
|
You can switch back to the old behavior, or choose to debug **all** Node.js scripts, using the **debug.javascript.autoAttachFilter** setting. If you want to change when the "smart" mode attaches, you can configure it in the **debug.javascript.autoAttachSmartPattern** setting.
|
|
|
|
|
|
|
|
|
|
As part of this, auto attach also now works with terminal multiplexers such as `tmux`, provided they inherit the session's environment variables.
|
|
|
|
|
As part of this, Auto Attach also now works with terminal multiplexers such as `tmux`, provided they inherit the session's environment variables.
|
|
|
|
|
|
|
|
|
|
#### Sourcemap Handling in Logged Errors
|
|
|
|
|
**Sourcemap handling in logged errors**
|
|
|
|
|
|
|
|
|
|
Previously, the stacktrace when logging a JavaScript error like `console.log(error)` would show the locations in your compiled code. If sourcemaps are available, VS Code will now process the stacktrace to use the source locations. This is particularly useful when debugging web apps that use bundlers like Webpack.
|
|
|
|
|
Previously, the stack trace when logging a JavaScript error like `console.log(error)` would show the locations in your compiled code. If sourcemaps are available, VS Code will now process the stack trace to use the source locations. This is useful when debugging web apps that use bundlers like Webpack.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously, a stacktrace like this would have referenced links in the compiled "bundle.js" file.
|
|
|
|
|
Previously, a stack trace like this would have referenced links in the compiled `bundle.js` file.
|
|
|
|
|
|
|
|
|
|
#### Notable Improvements
|
|
|
|
|
**Notable improvements**
|
|
|
|
|
|
|
|
|
|
- Previously, VS Code aggressively cached sourcemaps in a way that interfered with some types of tooling, such as Angular's `ng serve` and Nest.js `nest start --watch`. This is now fixed.
|
|
|
|
|
- When working in a remote (SSH, Containers, or WSL) VS Code did not support attaching to browsers already running locally; this is now fixed.
|
|
|
|
|
- You can now choose to stop if a conditional breakpoint throws an error by toggling the **debug.javascript.breakOnConditionalError** setting.
|
|
|
|
|
* Previously, VS Code aggressively cached sourcemaps in a way that interfered with some types of tooling, such as Angular's `ng serve` and Nest.js `nest start --watch`. This is now fixed.
|
|
|
|
|
* When working in a remote (SSH, Containers, or WSL), VS Code did not support attaching to browsers already running locally; this is now fixed.
|
|
|
|
|
* You can now choose to stop if a conditional breakpoint throws an error by toggling the **debug.javascript.breakOnConditionalError** setting.
|
|
|
|
|
|
|
|
|
|
## Contributions to extensions
|
|
|
|
|
|
|
|
|
|
@ -107,7 +106,7 @@ Previously, a stacktrace like this would have referenced links in the compiled "
|
|
|
|
|
|
|
|
|
|
**Improve cell execution order label discoverability**
|
|
|
|
|
|
|
|
|
|
Previously, the cell execute button would take the place of the execution order label when hovering or selecting a cell. This made it impossible to see the execution order label while executing a cell. We have moved it to sit below the execute button, aligned with the base of the editor. This should make it easier to find. (In this example, it's the `[6]`):
|
|
|
|
|
Previously, the cell execute button would take the place of the execution order label when hovering or selecting a cell. This made it impossible to see the execution order label while executing a cell. We have moved it to be below the execute button, aligned with the base of the editor. This should make it easier to find. (In this example, it's the `[6]`):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@ -115,23 +114,23 @@ Previously, the cell execute button would take the place of the execution order
|
|
|
|
|
|
|
|
|
|
We've added two settings that let users customize the cell appearance:
|
|
|
|
|
|
|
|
|
|
- `notebook.cellToolbarLocation`: Whether the toolbar should be shown on the left, the right, or hidden
|
|
|
|
|
- `notebook.showCellStatusBar`: Whether or not the cell status bar should be visible
|
|
|
|
|
* `notebook.cellToolbarLocation`: Whether the toolbar should be shown on the left, the right, or hidden.
|
|
|
|
|
* `notebook.showCellStatusBar`: Whether or not the cell Status bar should be visible.
|
|
|
|
|
|
|
|
|
|
**Cell status bar item contributions**
|
|
|
|
|
**Cell Status bar item contributions**
|
|
|
|
|
|
|
|
|
|
It's now possible for extensions to contribute custom items to the cell status bar, similarly to the VS Code status bar. These items can be buttons that trigger commands, or just plain text items. As an example, our Github issues notebook extension now contributes the "Open x results" command as a status bar item:
|
|
|
|
|
It's now possible for extensions to contribute custom items to the cell Status bar, similarly to the VS Code Status bar. These items can be buttons that trigger commands, or plain text items. As an example, our GitHub issues notebook extension now contributes the **Open x results** command as a Status bar item:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Enhanced Text Diff Editor**
|
|
|
|
|
**Enhanced text diff editor**
|
|
|
|
|
|
|
|
|
|
In this release we added a new type of diff editor for viewing changes in notebook documents. Traditinal notebooks are stored in JSON format, which is easy to parse but not effective on diffing since most diff algorithms on text files are line based. To improve this experience, we built an enhanced diff editor which is aware of notebook document and cells concept to help users quickly identify what cell content or metadata are changed.
|
|
|
|
|
In this release, we added a new type of diff editor for viewing changes in notebook documents. Traditional notebooks are stored in JSON format, which is easy to parse but not effective for diffing since most diff algorithms on text files are line-based. To improve this experience, we built an enhanced diff editor, which is aware of the concept of notebook documents and cells to help users quickly identify what cell content or metadata are changed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*Theme: [GitHub Theme](https://marketplace.visualstudio.com/items?itemName=GitHub.github-vscode-theme)*
|
|
|
|
|
|
|
|
|
|
You can still switch to regular text diff editor temporarily from the editor action toolbar or disable this feature by turning off setting `notebook.diff.enablePreview`.
|
|
|
|
|
You can still switch to regular text diff editor temporarily from the editor action tool bar or disable this feature by turning off the setting `notebook.diff.enablePreview`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@ -139,7 +138,7 @@ You can still switch to regular text diff editor temporarily from the editor act
|
|
|
|
|
|
|
|
|
|
Work continues on the [GitHub Pull Requests and Issues](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github) extension, which allows you to work on, create, and manage pull requests and issues. Some updates for this release include:
|
|
|
|
|
|
|
|
|
|
* Converted pull requests and issues to a multi-repo model to better align with how the build-in git extension works.
|
|
|
|
|
* Converted pull requests and issues to a multi-repo model to better align with how the build-in Git extension works.
|
|
|
|
|
|
|
|
|
|
To learn about all the new features and updates, you can see the full [changelog for the 0.20.0](https://github.com/microsoft/vscode-pull-request-github/blob/master/CHANGELOG.md#0200) release of the extension.
|
|
|
|
|
|
|
|
|
|
@ -156,7 +155,7 @@ Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 9
|
|
|
|
|
at MyProgram.main(MyFile.java:10)
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Using terminal link providers it is now possible to have a link for `java.lang.ArrayIndexOutOfBoundsException` that goes to API docs and create links for the symbols `MyProgram` or `main`.
|
|
|
|
|
Using terminal link providers, it is now possible to have a link for `java.lang.ArrayIndexOutOfBoundsException` that goes to API documentation and create links for the symbols `MyProgram` or `main`.
|
|
|
|
|
|
|
|
|
|
The following example implementation creates a link for the first instance of the word `"test"` on each line:
|
|
|
|
|
|
|
|
|
|
@ -185,24 +184,23 @@ window.registerTerminalLinkProvider({
|
|
|
|
|
});
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
### Debug Extension APIs
|
|
|
|
|
### Debug extension APIs
|
|
|
|
|
|
|
|
|
|
* **DebugAdapterNamedPipeServer**: VS Code offers three different ways of communication with Debug Adapters: via direct method calls, stdin/stdout, or TCP sockets. In this milestone we've added a fourth type: via "named pipes".
|
|
|
|
|
Our debugger sample "Mock Debug" [shows](https://github.com/microsoft/vscode-mock-debug/blob/f4b0e37cfd0cb1653c82a26bdab4910c87489713/src/extension.ts#L215-L244) how to use the `DebugAdapterNamedPipeServer`.
|
|
|
|
|
* **DebugAdapterNamedPipeServer**: VS Code offers three different ways of communication with Debug Adapters: via direct method calls, stdin/stdout, or TCP sockets. In this milestone, we've added a fourth type: via "named pipes". Our debugger sample "Mock Debug" [shows](https://github.com/microsoft/vscode-mock-debug/blob/f4b0e37cfd0cb1653c82a26bdab4910c87489713/src/extension.ts#L215-L244) how to use the `DebugAdapterNamedPipeServer`.
|
|
|
|
|
|
|
|
|
|
* **Changed timing of 'preLaunchTask'**: Before a debug session starts, the debug configuration's `preLaunchTask` is now launched inbetween the `resolveDebugConfiguration` and the `resolveDebugConfigurationWithSubstitutedVariables` calls of a `DebugConfigurationProvider`. Previously it was launched after both calls. For details please see [#95162](https://github.com/microsoft/vscode/issues/95162).
|
|
|
|
|
* **Changed timing of 'preLaunchTask'**: Before a debug session starts, the debug configuration's `preLaunchTask` is now launched in between the `resolveDebugConfiguration` and the `resolveDebugConfigurationWithSubstitutedVariables` calls of a `DebugConfigurationProvider`. Previously, it was launched after both calls. For details, see [issue #95162](https://github.com/microsoft/vscode/issues/95162).
|
|
|
|
|
|
|
|
|
|
* **Access Debug Adapter Protocol Breakpoints**: VS Code breakpoints are independent from debug adapters and they exist outside of debug sessions. When a debug sessions starts, VS Code breakpoints are registered with the debug adapter of the debug session and VS Code receives Debug Adapter Protocol (DAP) breakpoints in return. That means one VS Code breakpoint maps to zero, one, or more DAP breakpoints (depending on the number of concurrently active debug sessions).
|
|
|
|
|
VS Code maintains a mapping between its breakpoints and corresponding DAP breakpoints. In this milestone we've added API for accessing the mapping: a method `DebugSession.getDebugProtocolBreakpoint` returns a DAP breakpoint for a given VS Code breakpoint.
|
|
|
|
|
* **Access Debug Adapter Protocol Breakpoints**: VS Code breakpoints are independent from debug adapters and they exist outside of debug sessions. When a debug session starts, VS Code breakpoints are registered with the debug adapter of the debug session and VS Code receives Debug Adapter Protocol (DAP) breakpoints in return. That means one VS Code breakpoint maps to zero, one, or more DAP breakpoints (depending on the number of concurrently active debug sessions). VS Code maintains a mapping between its breakpoints and corresponding DAP breakpoints. In this milestone, we've added an API for accessing the mapping: the method `DebugSession.getDebugProtocolBreakpoint` returns a DAP breakpoint for a given VS Code breakpoint.
|
|
|
|
|
|
|
|
|
|
* **Finalized APIs**: Three proposed extension APIs for debugging have been finalized and can now be used in extensions published on the Marketplace:
|
|
|
|
|
|
|
|
|
|
* **Finalized APIs**: three proposed extension APIs for debugging have been finalized and can now be used in extensions published on the marketplace:
|
|
|
|
|
* The function `vscode.debug.stopDebugging` for stopping a single specific or all debug sessions. With this new API, it is no longer necessary to use the less predictable **Debug: Stop** command (command ID: `workbench.action.debug.stop`) which only stops the "active" debug session.
|
|
|
|
|
* The `noDebug` property of `DebugSessionOptions` controls whether the session about to start should run with or without debugging.
|
|
|
|
|
* The `compact` property of `DebugSessionOptions` controls whether the parent of the newly created debug session will be hidden in the CALL STACK view as long as it only has a single child.
|
|
|
|
|
|
|
|
|
|
### Task custom execution variable resolving
|
|
|
|
|
|
|
|
|
|
The API to resolve variables for custom execution tasks has been finalized. Variables in a custom execution task's defintion are resolved and then passed into the task's callback.
|
|
|
|
|
The API to resolve variables for custom execution tasks has been finalized. Variables in a custom execution task's definition are resolved and then passed into the task's callback.
|
|
|
|
|
|
|
|
|
|
```typescript
|
|
|
|
|
export class CustomExecution {
|
|
|
|
|
@ -219,66 +217,79 @@ export class CustomExecution {
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
### Task Detail
|
|
|
|
|
### Task detail
|
|
|
|
|
|
|
|
|
|
The task `detail` API, which is used to show additional information about a task in task quick picks, has been finalized.
|
|
|
|
|
The task `detail` API, which is used to show additional information about a task in the task Quick Pick, has been finalized.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Proposed extension APIs
|
|
|
|
|
|
|
|
|
|
Every milestone comes with new proposed APIs and extension authors can try them out. As always, we want your feedback. This is what you have to do to try out a proposed API:
|
|
|
|
|
|
|
|
|
|
* You must use Insiders because proposed APIs change frequently.
|
|
|
|
|
* You must have this line in the `package.json` file of your extension: `"enableProposedApi": true`.
|
|
|
|
|
* Copy the latest version of the [`vscode.proposed.d.ts`](https://github.com/microsoft/vscode/blob/master/src/vs/vscode.proposed.d.ts) file into your project's source location.
|
|
|
|
|
|
|
|
|
|
Note that you cannot publish an extension that uses a proposed API. There may be breaking changes in the next release and we never want to break existing extensions.
|
|
|
|
|
|
|
|
|
|
### Contributable context menu for Variables view
|
|
|
|
|
|
|
|
|
|
It is now possible for extensions to contribute commands to the context menu in the Variables view. More about menu contributions in general can be found [here](https://code.visualstudio.com/api/references/contribution-points#contributes.menus).
|
|
|
|
|
The Variables context menus has the following default groups which the extensions can contribute to:
|
|
|
|
|
It is now possible for extensions to contribute commands to the context menu in the Variables view. More about menu contributions in general can be found in the [API contributions points reference](https://code.visualstudio.com/api/references/contribution-points#contributes.menus).
|
|
|
|
|
|
|
|
|
|
The Variables context menus have the following default groups, which the extensions can contribute to:
|
|
|
|
|
|
|
|
|
|
* `navigation`: Commands related to navigation across VS Code. It is empty by default. This group always comes first.
|
|
|
|
|
* `1_view`: Commands related to displaying variables in different view formats. Empty by default.
|
|
|
|
|
* `3_modifications`: Commands related to modifications of variables. "Set Value" command
|
|
|
|
|
* `5_cutcopypaste`: Commands related to cutting, copying and pasting of variables. "Copy Value" and "Copy as Expression" commands
|
|
|
|
|
* `z_commands`: Other commands that do not belong to the above categories. "Add to Watch" and "Break on Value changes" commands. This group comes last.
|
|
|
|
|
* `3_modifications`: Commands related to modifications of variables. **Set Value** command.
|
|
|
|
|
* `5_cutcopypaste`: Commands related to cutting, copying and pasting of variables. **Copy Value** and **Copy as Expression** commands.
|
|
|
|
|
* `z_commands`: Other commands that do not belong to the above categories. **Add to Watch** and **Break on Value changes** commands. This group comes last.
|
|
|
|
|
|
|
|
|
|
As the context for these commands we pass the following object:
|
|
|
|
|
```
|
|
|
|
|
As the context for these commands, we pass the following object:
|
|
|
|
|
|
|
|
|
|
```json
|
|
|
|
|
{
|
|
|
|
|
container: DebugProtocolVariableContainer;
|
|
|
|
|
variable: DebugProtocolVariable;
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
`DebugProtocolVariableContainer` is an opaque stand-in type for the intersection of the `Scope` and `Variable` types defined in the Debug Adapter Protocol. A `DebugProtocolVariable` is an opaque stand-in type for the Variable type defined in the Debug Adapter Protocol.
|
|
|
|
|
|
|
|
|
|
In order to give greater context key flexibility to extensions we have introduced the following context key: `debugProtocolVariableMenuContext` which has the value of a `__vscodeVariableMenuContext` attribute from the Variable that the context menu is executed on. This context key should enable extensions to for example show array related commands only on variables that are arrays by passing the `__vscodeVariableMenuContext` attribute with a specific value for those variables.
|
|
|
|
|
In order to give greater context key flexibility to extensions, we have introduced the following context key: `debugProtocolVariableMenuContext`, which has the value of a `__vscodeVariableMenuContext` attribute from the Variable that the context menu is executed on. This context key should enable extensions, for example, to show array-related commands only on variables that are arrays by passing the `__vscodeVariableMenuContext` attribute with a specific value for those variables.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Engineering
|
|
|
|
|
|
|
|
|
|
### Web Playground moved to a separate repository
|
|
|
|
|
|
|
|
|
|
The extension that drives our [online web playground](https://vscode-web-test-playground.azurewebsites.net/) as well as `yarn web` when running out of sources moved into it's own [repository](https://github.com/microsoft/vscode-web-playground).
|
|
|
|
|
The extension that drives our [online web playground](https://vscode-web-test-playground.azurewebsites.net/), as well as `yarn web` when running out of sources, has moved into its own [repository](https://github.com/microsoft/vscode-web-playground).
|
|
|
|
|
|
|
|
|
|
### Web Playground support for different versions
|
|
|
|
|
|
|
|
|
|
Our [online web playground](https://vscode-web-test-playground.azurewebsites.net/) is now capable of running not only the latest insiders version of VSCode, but also the stable version or any released version by commit. New query parameters allow to drive this:
|
|
|
|
|
Our [online web playground](https://vscode-web-test-playground.azurewebsites.net/) is now capable of running not only the latest Insiders version of VS Code, but also the Stable version or any released version by commit.
|
|
|
|
|
|
|
|
|
|
New query parameters allow to drive this:
|
|
|
|
|
|
|
|
|
|
* `quality=<stable|insider>`
|
|
|
|
|
* `commit=<commit-sha>`
|
|
|
|
|
|
|
|
|
|
**Note:** if you specify a `commit` you must also specify it's associated `quality`.
|
|
|
|
|
**Note:** If you specify a `commit`, you must also specify it's associated `quality`.
|
|
|
|
|
|
|
|
|
|
### Minimal sandboxed workbench
|
|
|
|
|
|
|
|
|
|
We continue to explore enabling Electron's `sandbox` option in VSCode. During this milestone, we worked on allowing to bring up a minimal VSCode instance that is fully sandboxed by shimming a lot of the internals that today still require node.js access. This will be a multi-milestone journey and progress can be tracked at https://github.com/microsoft/vscode/issues/92164.
|
|
|
|
|
We continue to explore enabling Electron's `sandbox` option in VS Code. During this milestone, we worked on being able to bring up a minimal VS Code instance that is fully sandboxed by shimming various internals that today still require Node.js access. This will be a multi-milestone journey and you can track progress in [issue #92164](https://github.com/microsoft/vscode/issues/92164).
|
|
|
|
|
|
|
|
|
|
### Making VS Code Trusted Types compliant
|
|
|
|
|
|
|
|
|
|
We have started an effort to make VS Code "Trusted Types" compliant. The goal is to prevent DOM-based cross site scripting vulnerabilities. Learn more about trusted types here: https://web.dev/trusted-types/, follow our process here: https://github.com/microsoft/vscode/issues/103699
|
|
|
|
|
We have started an effort to make VS Code "Trusted Types" compliant. The goal is to prevent DOM-based cross site scripting vulnerabilities. You can learn more about trusted types at the web.dev [Trusted Types site](https://web.dev/trusted-types) and follow our progress in [issue #103699](https://github.com/microsoft/vscode/issues/103699).
|
|
|
|
|
|
|
|
|
|
## Notable fixes
|
|
|
|
|
|
|
|
|
|
* [38137](https://github.com/microsoft/vscode/issues/38137): Can't call sendText API or paste into terminal with long text
|
|
|
|
|
* [82604](https://github.com/microsoft/vscode/issues/82604): Web: editor does not provide a "Paste" action
|
|
|
|
|
* [101110](https://github.com/microsoft/vscode/issues/101110): Allow to configure workbench.editor.restoreViewState per language
|
|
|
|
|
* [102199](https://github.com/microsoft/vscode/issues/102199): JavaScript debugging: run to cursor can skip to next statement if cusor is after semicolon
|
|
|
|
|
* [102199](https://github.com/microsoft/vscode/issues/102199): JavaScript debugging: run to cursor can skip to next statement if cursor is after semicolon
|
|
|
|
|
* [103052](https://github.com/microsoft/vscode/issues/103052): Order of files in "Search files by name" results is incorrect
|
|
|
|
|
* [103105](https://github.com/microsoft/vscode/issues/103105): Debug: timeout after 1000 ms
|
|
|
|
|
* [103414](https://github.com/microsoft/vscode/issues/103414): Debug: better support when views are moved out of debug viewlet
|
|
|
|
|
|
Greg Van Liew
