Quick formatting and ordering pass
This commit is contained in:
Greg Van Liew
Родитель
497df20f00
Коммит
478f2999bd
|
|
@ -29,13 +29,12 @@ If you find issues or have suggestions, you can enter them in the [VS Code repos
|
|||
|
||||
### Compact folders in Explorer
|
||||
|
||||
In the Explorer we are now rendering single child folders in a compact form. In such a form, single child folders will be compressed in a combined tree element. Useful for Java package structures, for example.
|
||||
In the File Explorer, we now render single child folders in a compact form. In such a form, single child folders will be compressed in a combined tree element. Useful for Java package structures, for example.
|
||||
|
||||
Setting `explorer.compactFolders` controls this behavior. By default this setting is turned on.
|
||||
Setting `explorer.compactFolders` controls this behavior. By default, this setting is turned on.
|
||||
|
||||
|
||||
|
||||
|
||||
### Edit left-hand side in diffs
|
||||
|
||||
If you compare two editors that are editable (for example, from the File Explorer by comparing two files or running a global Search & Replace), the left-hand side is now also editable and can be saved (`kb(workbench.action.files.save)`).
|
||||
|
|
@ -54,11 +53,11 @@ If you bring up a peek view and type into it, you can now save it via `kb(workbe
|
|||
|
||||
Reading and writing files (from the text editor) should now be faster for scenarios where the file system is remote and the latency is high (for example when using VS Code in a browser with a slow connection or being connected to a remote host that is not in the same region). We switched to a stream-based implementation for reads and writes that greatly reduces communication overhead.
|
||||
|
||||
### Problems Panel
|
||||
### Problems panel
|
||||
|
||||
**More Filters**
|
||||
|
||||
More predefined filters are added to the problems panel. You can now filter problems by type and also see problems scoped to the current active file.
|
||||
More predefined filters are added to the Problems panel. You can now filter problems by type and also see problems scoped to the current active file.
|
||||
|
||||
|
||||
|
||||
|
|
@ -66,7 +65,7 @@ Theme: GitHub Sharp Dark, Font: FiraCode
|
|||
|
||||
**Show current problem in Status bar**
|
||||
|
||||
You can now configure VS Code to show the current problem message in the status bar. This will allow you to see the summary of the problem that is selected in the opened file without any additional keyboard or mouse gestures.
|
||||
You can now configure VS Code to show the current problem message in the Status bar. This will allow you to see the summary of the problem that is selected in the opened file without any additional keyboard or mouse gestures.
|
||||
|
||||
**Note:** Enabling this feature needs enabling the setting `problems.showCurrentInStatus`.
|
||||
|
||||
|
|
@ -76,7 +75,7 @@ Theme: GitHub Sharp Dark, Font: FiraCode
|
|||
|
||||
**Flexible filter box layout**
|
||||
|
||||
Filter box in the problems panel adjusts its position nicely according to the panel's position and size.
|
||||
Filter box in the Problems panel adjusts its position nicely according to the panel's position and size.
|
||||
|
||||
|
||||
|
||||
|
|
@ -92,7 +91,7 @@ This is customized via the `editor.gotoLocation.alternativeDefinitionCommand` se
|
|||
|
||||
### Peek, Go to, and Find All commands
|
||||
|
||||
Each **Peek** command now has a **Go to** counterpart. For instance, there is now both **Peek Implementations** and **Go to Implementations**. The Peek view doesn't change the current editor and allows for a quick in-place look at source code.
|
||||
Each **Peek** command now has a **Go to** counterpart. For instance, there are now both **Peek Implementations** and **Go to Implementations**. The Peek view doesn't change the current editor and allows for a quick in-place look at source code.
|
||||
|
||||
The video below shows all implementations of the `ICommandService` interface:
|
||||
|
||||
|
|
@ -153,9 +152,9 @@ Content changes decorations are also shown in the gutter of the minimap, and can
|
|||
|
||||
### editor.accessibilityPageSize
|
||||
|
||||
We have introduced the setting `editor.accessibilityPageSize` that controls the number of lines in the editor that can be read out by a screen reader at once. Warning: this has a performance implication for numbers larger than the default of 10.
|
||||
There is a new setting `editor.accessibilityPageSize` that controls the number of lines in the editor that can be read out by a screen reader at once. Note that this has performance implications for numbers larger than the default of 10.
|
||||
|
||||
For users that use the screen reader "Say All" command we recommend setting `editor.accessibilityPageSize` to 100 or 1000. Next milestone we will look into changing the default value of this setting.
|
||||
For users that use the screen reader **Say All** command, we recommend setting `editor.accessibilityPageSize` to 100 or 1000. Next milestone, we will look into changing the default value of this setting.
|
||||
|
||||
## Integrated terminal
|
||||
|
||||
|
|
@ -211,63 +210,75 @@ Then the colors will increase or decrease luminance until either the contrast ra
|
|||
|
||||
Theme: Sapphire, Font: Hack
|
||||
|
||||
## Browser support
|
||||
|
||||
### Improved support for Firefox and Safari (macOS & iPadOS)
|
||||
|
||||
During this milestone, we focused on improving the experience of VS Code running in a browser when using Firefox or Safari. We fixed many issues to support both browsers ([Firefox](https://github.com/Microsoft/vscode/issues?q=is%3Aissue+label%3Afirefox+is%3Aclosed+milestone%3A%22November+2019%22), [Safari](https://github.com/Microsoft/vscode/issues?q=is%3Aissue+label%3Asafari+is%3Aclosed+milestone%3A%22November+2019%22)).
|
||||
|
||||
<!-- TODO@Pung mention iPadOS improvements. -->
|
||||
|
||||
### More features available running in a browser
|
||||
|
||||
Last milestone, we [introduced support](https://code.visualstudio.com/updates/v1_40#_test-vs-code-running-in-a-browser) for running `yarn web` from our repository to set up VS Code running in the browser. This setup is still meant to be used for testing issues in browsers and not for development.
|
||||
|
||||
This milestone we added more features that can be tested:
|
||||
|
||||
* Debug
|
||||
* Search
|
||||
* Tasks
|
||||
* Problems
|
||||
|
||||
Here is a video showing the new features in action:
|
||||
|
||||
|
||||
|
||||
## Debugging
|
||||
|
||||
We have introduced the setting `debug.showInlineBreakpointCandidates` that controls whether inline breakpoints candidate decorations should be shown in the editor while debugging. By default they are visible.
|
||||
|
||||
## Languages
|
||||
|
||||
### JSON
|
||||
|
||||
To avoid performance issues with large files, the JSON language supports has a upper limit of folding regions and document symbols (for outline, breadcrumb) it computes. By the default the limit it is 5000, but you can change the limit with the setting `json.maxItemsComputed`.
|
||||
To avoid performance issues with large files, the JSON language support has an upper limit of folding regions and document symbols (for outline, breadcrumb) it computes. By the default, the limit is 5000, but you can change the limit with the setting `json.maxItemsComputed`.
|
||||
|
||||
|
||||
|
||||
## Debugging
|
||||
|
||||
### UX improvements
|
||||
A new setting `debug.showInlineBreakpointCandidates` controls whether inline breakpoints candidate decorations should be shown in the editor while debugging. By default, they are visible.
|
||||
|
||||
#### Debug START view
|
||||
### Debug START view
|
||||
|
||||
We have introduced a new debug START view to make it easier for users to start and configure debugging in a new workspace.
|
||||
Based on the active file we will choose the appropriate debug extension and make it possible to debug or run your app. For more elaborate debug and run configuration it is best to configure a `launch.json` file.
|
||||
We have introduced a new debug START view to make it easier for users to start and configure debugging in a new workspace. Based on the active file, we will choose the appropriate debug extension and make it possible to debug or run your app. For more elaborate debug and run configurations, it is best to configure a `launch.json` file.
|
||||
|
||||
|
||||
|
||||
#### Restart frame as an inline action in the CALL STACK view
|
||||
### Restart frame as an inline action in the CALL STACK view
|
||||
|
||||
To improve the discoverability of the Restart Frame action we have introduced it as an inline action in the CALL STACK view visible on hover. Restarting frames is a handy way to re-run the preceding code after a breakpoint is hit. If the debug extension does not support restarting frames we will not show this action.
|
||||
To improve the discoverability of the **Restart Frame** action, we have introduced it as an inline action in the CALL STACK view visible on hover. Restarting frames is a handy way to rerun the preceding code after a breakpoint is hit. If the debug extension does not support restarting frames, we will not show this action.
|
||||
|
||||
|
||||
|
||||
#### Debug console: clearer indication of what is input and what is output
|
||||
### Debug console: clearer indication of what is input and what is output
|
||||
|
||||
In order to distinguish input and output better in the debug console we have introduced opaque decorations to the left.
|
||||
In order to distinguish input and output better in the Debug console, we have introduced opaque decorations to the left.
|
||||
|
||||
|
||||
|
||||
## Extensions contributions
|
||||
|
||||
### ESLint
|
||||
|
||||
Improvements to the VS Code ESLint extension:
|
||||
|
||||
* Better support for ESLint 6.x. In most cases, it shouldn't be necessary to configure working directories when using ESLint 6.x.
|
||||
* Improved TypeScript detection. As soon as TypeScript is correctly configured inside ESLint, there is no need anymore for an additional configuration of TypeScript ESLint inside of VS Code's `eslint.validate` setting. The same is true for HTML and VUE files.
|
||||
* Glob working directory support. Projects that have a complex folder setup and do need to customize the working directories via `eslint.workingDirectories` can now use glob patterns instead of listing every project folder (for example `code-*` will match all project folders starting with `code-`). In addition, the extension now changes the working directory by default. If that needs to be disabled users can use the new `!cwd` property.
|
||||
* Improved auto fix on save. Auto fix on save is now part of VS Code's code action on save infrastructure and computes all possible fixes in one round. It is customized via the `editor.codeActionsOnSave` setting. The setting supports the ESLint specific property `source.fixAll.eslint`. The extension also respects the generic property `source.fixAll`.
|
||||
|
||||
For example:
|
||||
|
||||
```json
|
||||
"editor.codeActionsOnSave": {
|
||||
"source.fixAll": true
|
||||
}
|
||||
```
|
||||
|
||||
turns on auto fix for all providers including ESLint.
|
||||
|
||||
In contrast:
|
||||
|
||||
```json
|
||||
"editor.codeActionsOnSave": {
|
||||
"source.fixAll.eslint": true
|
||||
}
|
||||
```
|
||||
|
||||
only turns it on for ESLint.
|
||||
|
||||
You can also selectively disable ESLint via:
|
||||
|
||||
```json
|
||||
"editor.codeActionsOnSave": {
|
||||
"source.fixAll": true,
|
||||
"source.fixAll.eslint": false
|
||||
}
|
||||
```
|
||||
|
||||
## Extension authoring
|
||||
|
||||
|
|
@ -293,7 +304,7 @@ The [`TextDocument.getWordRangeAtPosition`](https://github.com/microsoft/vscode/
|
|||
|
||||
### Deprecated string type for extensionKind
|
||||
|
||||
Extension authors can use `extnsionKind` property in `package.json` to indicate where the extension should run in the remote case. As of previous release (1.40), this value can be a string or an array. From this release this property supports only array value and the string type is deprecated. Please see the [documentation](https://code.visualstudio.com/api/advanced-topics/remote-extensions#incorrect-execution-location) for more information.
|
||||
Extension authors can use `extnsionKind` property in `package.json` to indicate where the extension should run in the remote case. As of previous release (1.40), this value can be a string or an array. Starting with this release, this property supports only array value and the string type is deprecated. See the [documentation](https://code.visualstudio.com/api/advanced-topics/remote-extensions#incorrect-execution-location) for more information.
|
||||
|
||||
### Debug API: debug.asDebugSourceUri
|
||||
|
||||
|
|
@ -310,34 +321,28 @@ export async function openDAPSource(session: vscode.DebugSession, source: DebugP
|
|||
|
||||
Proposed support got to provide a [call hierarchy](https://github.com/microsoft/vscode-languageserver-node/blob/dbaeumer/moreIntegrationTests/protocol/src/protocol.callHierarchy.proposed.ts#L1) via LSP.
|
||||
|
||||
## Extensions
|
||||
## Browser support
|
||||
|
||||
### ESLint
|
||||
### Improved support for Firefox and Safari (macOS & iPadOS)
|
||||
|
||||
The VS Code ESLint extension
|
||||
During this milestone, we focused on improving the experience of VS Code running in a browser when using Firefox or Safari. We fixed many issues to support both browsers ([Firefox](https://github.com/Microsoft/vscode/issues?q=is%3Aissue+label%3Afirefox+is%3Aclosed+milestone%3A%22November+2019%22), [Safari](https://github.com/Microsoft/vscode/issues?q=is%3Aissue+label%3Asafari+is%3Aclosed+milestone%3A%22November+2019%22)).
|
||||
|
||||
- better support for ESLint 6.x: in most cases it shouldn't be necessary anymore to configure working directories when using ESLint 6.x.
|
||||
- improved TypeScript detection: as soon as TypeScript is correctly configured inside ESLint there is no need anymore for an additional configuration of TypeScript ESLint inside of VS Code's `eslint.validate` setting. The same is true for HTML and VUE files.
|
||||
- glob working directory support: projects that have a complex folder setup and do need to customize the working directories via `eslint.workingDirectories` can now use glob patterns instead of listing every project folder (e.g `code-*` will match all project folders starting with `code-`). In addition the extension now changes the working directory by default. If that needs to be disabled users can use the new `!cwd` property.
|
||||
- improved auto fix on save: auto fix on save is now part of VS Code's code action on save infrastructure and computes all possible fixes in one round. It is customized via the `editor.codeActionsOnSave` setting. The setting supports the ESLint specific property `source.fixAll.eslint`. The extension also respects the generic property `source.fixAll`. For example
|
||||
```json
|
||||
"editor.codeActionsOnSave": {
|
||||
"source.fixAll": true
|
||||
}
|
||||
```
|
||||
turns auto fix on for all providers including ESLint. In contrast
|
||||
```json
|
||||
"editor.codeActionsOnSave": {
|
||||
"source.fixAll.eslint": true
|
||||
}
|
||||
```
|
||||
only turns it on for ESLint. You can also selectively disable ESLint via
|
||||
```json
|
||||
"editor.codeActionsOnSave": {
|
||||
"source.fixAll": true,
|
||||
"source.fixAll.eslint": false
|
||||
}
|
||||
```
|
||||
<!-- TODO@Pung mention iPadOS improvements. -->
|
||||
|
||||
### More features available running in a browser
|
||||
|
||||
Last milestone, we [introduced support](https://code.visualstudio.com/updates/v1_40#_test-vs-code-running-in-a-browser) for running `yarn web` from our repository to set up VS Code running in the browser. This setup is still meant to be used for testing issues in browsers and not for development.
|
||||
|
||||
This milestone we added more features that can be tested:
|
||||
|
||||
* Debug
|
||||
* Search
|
||||
* Tasks
|
||||
* Problems
|
||||
|
||||
Here is a video showing the new features in action:
|
||||
|
||||
|
||||
|
||||
## Engineering
|
||||
|
||||
|
|
@ -353,8 +358,6 @@ The Insiders build is now available in the yum repository and is automatically p
|
|||
* [83449](https://github.com/microsoft/vscode/issues/83449): Accessibility: Ctrl+Right in accessibility mode (CursorWordAccessibilityRight) should jump to the beginning of next word, rather than the end
|
||||
* [83753](https://github.com/microsoft/vscode/issues/83753): Disabling console.debug.wordWrap strips newlines and whitespace
|
||||
|
||||
|
||||
|
||||
## Thank you
|
||||
|
||||
Last but certainly not least, a big *__Thank You!__* to the following folks that helped to make VS Code even better:
|
||||
|
|
|
|||
|
|
@ -4,7 +4,9 @@
|
|||
|
||||
### Multi extensionKind support
|
||||
|
||||
VS Code now supports running extensions defined with multiple extension kinds. Following table shows given the extension with extensionKind(s), where VS Code enables/installs the extension.
|
||||
VS Code now supports running extensions defined with multiple extension kinds.
|
||||
|
||||
The following table shows given the extension with extensionKind(s), where VS Code enables/installs the extension.
|
||||
|
||||
| Extension Kind \ Location | Local (Only) | Remote (Only) | Both |
|
||||
| :--- | :----: | :----: | :--- |
|
||||
|
|
@ -17,13 +19,13 @@ Please see the [documentation](https://code.visualstudio.com/api/advanced-topics
|
|||
|
||||
### Download extensions locally
|
||||
|
||||
You can now configure VS Code to download extensions always locally while installing extensions in a remote window. To enable this use setting `remote.downloadExtensionsLocally`.
|
||||
You can now configure VS Code to download extensions always locally while installing extensions in a remote window. To enable this, use setting `remote.downloadExtensionsLocally`.
|
||||
|
||||
## WSL
|
||||
|
||||
### Support for ARM
|
||||
|
||||
The VSCode Remote Server now also runs on Windows 10 ARM-based PCs such as the Surface Pro X.
|
||||
The VS Code Remote Server now also runs on Windows 10 ARM-based PCs such as the Surface Pro X.
|
||||
|
||||
### Server download and install improvements
|
||||
|
||||
|
|
@ -31,8 +33,8 @@ Downloading the server behind proxies had been improved. Downloads and the unpac
|
|||
|
||||
### Multi distro support for WSL on Windows 10 builds 1803 and 1809
|
||||
|
||||
Users on Windows 10 1803 and 1809 now can open any distro. If the distro is not the default distro, the Remote WSL extension will ask if it's ok the change the default distro.
|
||||
Users on Windows 10 1803 and 1809 now can open any Linux distribution. If the distro is not the default, the Remote WSL extension will ask if it's ok the change the default distro.
|
||||
|
||||
### Open folder and reload performance
|
||||
|
||||
Changing the input of a Remote WSL Window is now much faster.
|
||||
Changing the input of a Remote WSL Window is now much faster.
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче