Edits to recent 1.49 release notes
This commit is contained in:
Greg Van Liew
Родитель
4f5c8f3d7f
Коммит
c54b990a3c
|
|
@ -56,11 +56,11 @@ Pick a command with the keybinding you think is overloaded and you can see if mu
|
|||
|
||||
## Troubleshooting keybindings
|
||||
|
||||
To troubleshoot keybindings problems, you can execute the command `Developer: Toggle Keyboard Shortcuts Troubleshooting`. This will activate logging of dispatching keyboard shortcuts and will open an output panel with the corresponding log file.
|
||||
To troubleshoot keybindings problems, you can execute the command **Developer: Toggle Keyboard Shortcuts Troubleshooting**. This will activate logging of dispatched keyboard shortcuts and will open an output panel with the corresponding log file.
|
||||
|
||||
Then, if you press your desired keybinding, you can check what VS Code detects and what command is invoked.
|
||||
You can then press your desired keybinding and check what keyboard shortcut VS Code detects and what command is invoked.
|
||||
|
||||
e.g. Pressing `cmd+/` in a code editor, on a macbook:
|
||||
For example, when pressing `cmd+/` in a code editor on macOS, the logging output would be:
|
||||
|
||||
```
|
||||
[KeybindingService]: / Received keydown event - modifiers: [meta], code: MetaLeft, keyCode: 91, key: Meta
|
||||
|
|
@ -72,7 +72,7 @@ e.g. Pressing `cmd+/` in a code editor, on a macbook:
|
|||
[KeybindingService]: \ From 2 keybinding entries, matched editor.action.commentLine, when: editorTextFocus && !editorReadonly, source: built-in.
|
||||
```
|
||||
|
||||
The first keydown event is for the `MetaLeft` key (`cmd`) and cannot be dispatched. The second keydown event is for the `Slash` key (`/`) and is dispatched as `meta+[Slash]`. There were two keybinding entries mapped from `meta+[Slash]` and the one that matched was for the command `editor.action.commentLine`, had the `when` condition `editorTextFocus && !editorReadonly` and was a built in keybinding entry.
|
||||
The first keydown event is for the `MetaLeft` key (`cmd`) and cannot be dispatched. The second keydown event is for the `Slash` key (`/`) and is dispatched as `meta+[Slash]`. There were two keybinding entries mapped from `meta+[Slash]` and the one that matched was for the command `editor.action.commentLine`, which has the `when` condition `editorTextFocus && !editorReadonly` and is a built-in keybinding entry.
|
||||
|
||||
## Viewing modified keybindings
|
||||
|
||||
|
|
|
|||
|
|
@ -42,11 +42,19 @@ This also requires that the active formatter supports to formatting only a porti
|
|||
|
||||
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 cursor move on type control
|
||||
|
||||
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`.
|
||||
|
||||
|
||||
|
||||
|
||||
### Only show trailing whitespace
|
||||
|
||||
There is a new option `trailing` for the editor setting `editor.rendersWhitespace` to only show trailing whitespace.
|
||||
|
||||
```json
|
||||
"editor.renderWhitespace": "trailing"
|
||||
```
|
||||
|
||||
## Workbench
|
||||
|
||||
|
|
@ -60,11 +68,11 @@ The new `screencastMode.mouseIndicatorColor` and `screencastMode.mouseIndicatorS
|
|||
|
||||
### Troubleshooting keybindings
|
||||
|
||||
To troubleshoot keybindings problems, you can now execute the command `Developer: Toggle Keyboard Shortcuts Troubleshooting`. This will activate logging of dispatching keyboard shortcuts and will open an output panel with the corresponding log file.
|
||||
To troubleshoot keybindings problems, there is now a command **Developer: Toggle Keyboard Shortcuts Troubleshooting**. This will activate logging of dispatched keyboard shortcuts and will open an output panel with the corresponding log file.
|
||||
|
||||
Then, if you press your desired keybinding, you can check what VS Code detects and what command is invoked.
|
||||
You can then press your desired keybinding and check what keyboard shortcut VS Code detects and what command is invoked.
|
||||
|
||||
e.g. Pressing `cmd+/` in a code editor, on a macbook:
|
||||
For example, when pressing `cmd+/` in a code editor on macOS, the logging output would be:
|
||||
|
||||
```
|
||||
[KeybindingService]: / Received keydown event - modifiers: [meta], code: MetaLeft, keyCode: 91, key: Meta
|
||||
|
|
@ -76,15 +84,15 @@ e.g. Pressing `cmd+/` in a code editor, on a macbook:
|
|||
[KeybindingService]: \ From 2 keybinding entries, matched editor.action.commentLine, when: editorTextFocus && !editorReadonly, source: built-in.
|
||||
```
|
||||
|
||||
The first keydown event is for the `MetaLeft` key (`cmd`) and cannot be dispatched. The second keydown event is for the `Slash` key (`/`) and is dispatched as `meta+[Slash]`. There were two keybinding entries mapped from `meta+[Slash]` and the one that matched was for the command `editor.action.commentLine`, had the `when` condition `editorTextFocus && !editorReadonly` and was a built in keybinding entry.
|
||||
The first keydown event is for the `MetaLeft` key (`cmd`) and cannot be dispatched. The second keydown event is for the `Slash` key (`/`) and is dispatched as `meta+[Slash]`. There were two keybinding entries mapped from `meta+[Slash]` and the one that matched was for the command `editor.action.commentLine`, which has the `when` condition `editorTextFocus && !editorReadonly` and is a built-in keybinding entry.
|
||||
|
||||
## Source Control
|
||||
|
||||
### Source Control Repositories View
|
||||
### Source Control Repositories view
|
||||
|
||||
The Source Control Repositories view (formerly known as Source Control Providers view) was reintroduced to allow finer grain control over which source control repositories should be visible in the Source Control view. As before, this view supports multiple selection so you can have multiple repositories visible at the same time.
|
||||
|
||||
|
||||
|
||||
|
||||
## Debugging
|
||||
|
||||
|
|
@ -92,14 +100,14 @@ The Source Control Repositories view (formerly known as Source Control Providers
|
|||
|
||||
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, 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
|
||||
|
||||
|
|
@ -107,7 +115,7 @@ The Debug Console now supports filtering, making it easier for users to find the
|
|||
|
||||
[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.
|
||||
|
|
@ -118,7 +126,7 @@ As part of this, Auto Attach also now works with terminal multiplexers such as `
|
|||
|
||||
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 stack trace like this would have referenced links in the compiled `bundle.js` file.
|
||||
|
||||
|
|
@ -128,12 +136,6 @@ Previously, a stack trace like this would have referenced links in the compiled
|
|||
* 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.
|
||||
|
||||
## Editor
|
||||
|
||||
### New `trailing` option for `editor.renderWhitespace`
|
||||
|
||||
When configured with `"editor.renderWhitespace": "trailing"`, only trailing whitespace will be rendered in the editor.
|
||||
|
||||
## Contributions to extensions
|
||||
|
||||
### Notebooks
|
||||
|
|
@ -142,7 +144,7 @@ When configured with `"editor.renderWhitespace": "trailing"`, only trailing whit
|
|||
|
||||
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]`):
|
||||
|
||||
|
||||
|
||||
|
||||
**Customize cell appearance**
|
||||
|
||||
|
|
@ -155,7 +157,7 @@ We've added two settings that let users customize the cell appearance:
|
|||
|
||||
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**
|
||||
|
||||
|
|
@ -254,6 +256,7 @@ export class CustomExecution {
|
|||
### Task detail
|
||||
|
||||
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
|
||||
|
|
@ -274,13 +277,14 @@ Instances of `SourceControlResourceState` now support an optional `contextValue:
|
|||
|
||||
We've added command contribution support for the context menu in the Variables view. This makes it possible to implement frequently requested features like variable formatting (e.g. "View as Hex") or viewing variables in custom data views:
|
||||
|
||||
|
||||
|
||||
|
||||
When a registered context menu command is executed, both the underlying variable and its container are passed as Debug Adapter Protocol (DAP) objects. Please note that VS Code's extension API uses opaque stand-in types instead of the real DAP types. In order to access their properties, they can be easily coerced into the corresponding DAP types.
|
||||
|
||||
Menu contributions for the Variables view are identified by a `"debug/variables/context"` key. General information about menu contributions can be found [here](https://code.visualstudio.com/api/references/contribution-points#contributes.menus).
|
||||
Menu contributions for the Variables view are identified by a `"debug/variables/context"` key. General information about menu contributions can be found in the [contributions points documentation](https://code.visualstudio.com/api/references/contribution-points#contributes.menus).
|
||||
|
||||
To help with structuring menu commands into meaningful groups, we have added some predefined groups:
|
||||
|
||||
* `navigation`: Commands related to navigation across VS Code. This group always comes first and is currently empty by default.
|
||||
* `1_view`: Commands related to displaying variables in different view formats. Currently empty by default.
|
||||
* `3_modifications`: Commands related to modifications of variables. Currently home of the "Set Value" command.
|
||||
|
|
@ -288,6 +292,7 @@ To help with structuring menu commands into meaningful groups, we have added som
|
|||
* `z_commands`: Other commands that do not belong to the above categories. This group comes last and currently contains the "Add to Watch" and "Break on Value changes" commands.
|
||||
|
||||
Typically, menu contributions in the Variables view should only apply to a specific debug type. This can be easily achieved by adding a "when" clause to the contribution. Here is one for Java:
|
||||
|
||||
```js
|
||||
"when": "debugConfigurationType == 'java'"
|
||||
```
|
||||
|
|
@ -295,6 +300,7 @@ Typically, menu contributions in the Variables view should only apply to a speci
|
|||
Since some menu contributions should only be available for variables of a specific kind, we have introduced a new optional context key `debugProtocolVariableMenuContext`, which receives its value from a property `__vscodeVariableMenuContext` of the underlying DAP type `Variable` (please note that the `__vscodeVariableMenuContext` property is not part of the DAP specification, because it is specific to VS Code and its menu contribution support).
|
||||
|
||||
This makes it possible to show an array related menu command only on variables where a property `__vscodeVariableMenuContext` got a value `'array'` from the debug adapter:
|
||||
|
||||
```js
|
||||
"contributes": {
|
||||
"menus": {
|
||||
|
|
|
|||
|
|
@ -30,20 +30,24 @@ If VS Code can not find any containers, the Welcome view will prompt you to open
|
|||
|
||||
### Support for Docker Compose when cloning repository in container volume
|
||||
|
||||
Cloning a repository in a container volume (`F1` > `Remote-Containers: Clone Repository in Container Volume...`) now also supports DevContainers using Docker Compose.
|
||||
Cloning a repository in a container volume with the **Remote-Containers: Clone Repository in Container Volume** command now also supports DevContainers using Docker Compose.
|
||||
|
||||
### Support to Select a GitHub repository when cloning a reposity in a container volume
|
||||
### Select a GitHub repository when cloning a repository in a container volume
|
||||
|
||||
When Cloning a repository in a container volume you can now select a GitHub repository.
|
||||
When cloning a repository in a container volume, you can now select a GitHub repository.
|
||||
|
||||
|
||||
|
||||
|
||||
### DevContainer definitions configuration options
|
||||
|
||||
The DevContainer definitions now come with install and configuration options that are shown after picking a definition (`F1` > `Remote-Containers: Add Development Container Configuration Files...`):
|
||||
DevContainer definitions now come with install and configuration options that are shown after picking a definition with the **Remote-Containers: Add Development Container Configuration Files** command.
|
||||
|
||||
In the example below, when configuring a Java DevContainer, there is the option to select the Java version:
|
||||
|
||||
|
||||
|
||||
and then choose one or more optional frameworks:
|
||||
|
||||
|
||||
|
||||
## WSL
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче