**Update 1.56.1**: The update addresses these security [issues](https://github.com/microsoft/vscode/issues?q=is%3Aissue+milestone%3A%22April+2021+Recovery%22+is%3Aclosed).
**Update 1.56.2**: The update addresses these [issues](https://github.com/microsoft/vscode/issues?q=is%3Aissue+milestone%3A%22April+2021+Recovery+2%22+is%3Aclosed).
Welcome to the April 2021 release of Visual Studio Code. The VS Code team has been busy this month working on several longer lead time updates so check out the [Preview features](#preview-features) section to learn what's upcoming. Here are some of the highlights included in this release:
>If you'd like to read these release notes online, go to [Updates](https://code.visualstudio.com/updates) on [code.visualstudio.com](https://code.visualstudio.com).
**Join us live** at the [VS Code team's livestream](https://code.visualstudio.com/livestream) on Tuesday, May 11 at 8am Pacific (4pm London) to see a demo of what's new in this release, and ask us questions live.
**Insiders:** Want to try new features as soon as possible? You can download the nightly [Insiders](https://code.visualstudio.com/insiders) build and try the latest updates as soon as they are available.
We have noticed that many new users are not aware that a language has to be set in order to get full VS Code language support. To help with this problem, we have introduced a hint for untitled editors to help users set the correct language mode. The untitled hint might not be helpful to advanced users, so it goes away immediately as you start typing or you can select **don't show** to never display the hint again.
If you have two editors that both state they should be your default editor for a resource (for example, an image viewer and an image editor), you will receive a prompt to resolve the conflict.
In the short video below, the user opens a PNG file, which is associated with two editors. The notification lets the user keep using the Luna Paint Image Editor or configure a new default, which they do and start using the binary Hex Editor.
We have updated our custom dialog styles, which you can enable via `"window.dialogStyle": "custom"`. VS Code now dims the background so there is better focus on the dialog and also uses the secondary button style when there is more than one action.
Last iteration, we introduced [terminal profiles](https://code.visualstudio.com/updates/v1_55#_terminal-profiles). The terminal now supports setting a default profile with the `terminal.integrated.defaultProfile.<platform>` settings.
Environment and icon support was also added to the profiles system:
Going forward, these settings are the recommended way to switch out the default terminal configuration and the `terminal.integrated.shell` and `terminal.integrated.shellArgs` settings have been deprecated.
As always, these default keybindings can be removed or custom keybindings can be added via the [keybindings system](https://code.visualstudio.com/docs/getstarted/keybindings).
In order to support incoming changes related to profiles, the prompt that would show if terminal settings were present in `.vscode/settings.json` was removed in favor of a setting to opt into workspace settings use. Note that this can be dangerous in untrusted workspaces.
Tasks 2.0.0 has been available and working well for over three years, and tasks 0.1.0 has been deprecated throughout that time. In light of our [Node.js-free renderer](https://github.com/microsoft/vscode/issues/92164) goal, tasks 0.1.0 has been deleted rather than brought into the Node.js-free world. When you open a folder that contains 0.1.0 tasks, they will be automatically upgraded to version 2.0.0 for you.
When using the new [Terminal tabs](#terminal-tabs) feature, the "Task" prefix will no longer be added to the terminal name. Instead, tasks are indicated by the "tools" icon to make better use of the available space.
For exception breakpoints, VS Code now shows their individual verification status and detailed reason in the Breakpoints view. If an exception breakpoint cannot be verified (for example because its condition contains a syntax error), it will be grayed out and, on hover, the corresponding error message is shown.
A debug session is typically stopped via the **Debug: Stop** and **Debug: Disconnect** commands. If the debug session is of type `launch`, the **Stop** command does not only stop the session but it also terminates the debuggee. For `attach` type debug sessions, there is a **Disconnect** command, which stops debugging and resumes execution of the debuggee.
With this release, it is now possible to flip this behavior by pressing the `Alt` modifier while triggering the command from the Debug toolbar. Altering the behavior makes it possible to leave the debuggee running for `launch` type debug sessions, and to terminate the debuggee for `attach` type debug sessions. Apart from using `Alt` with the default commands, it is also possible to access both the **Debug: Stop** and **Debug: Disconnect** commands from the Command Palette for both `launch` and `attach` debug sessions.
We have improved the flow if a user wants to start debugging but hasn't installed the necessary language extension that provides debugging support (like Python or Java). When this happens, VS Code now prompts the user to install the appropriate extension.
VS Code now renders the Call Stack column indicator every time a debuggee is stopped on a line. This should help identify where on a line the program is currently stopped.
VS Code's debugger UI supports **Inline values** that show variable values **inline** in the editor when stepping through source code. This feature is based on a generic implementation in VS Code core and so may not be a perfect fit for all languages, even sometimes showing incorrect values because the generic approach doesn't understand the underlying source language. For these reasons, the feature was not enabled by default.
With a new debugger extension API, it is now possible for language extensions to provide correct inline value support and we are enabling the **Improved inline values** feature by default.
To enable this feature, the `debug.inlineValues` setting has a new (default) value `auto`. When set to `auto`, inline values are automatically enabled for those languages that have "improved inline value" support.
The [Debugger for Java](https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-debug) extension is one of the first debugger extensions to adopt the API. In the screenshot below, the accurate values of the Java variables are displayed right next to their usage.
You can get inline values while debugging PowerShell scripts using the [Inline Values support for PowerShell](https://marketplace.visualstudio.com/items?itemName=TylerLeonhardt.vscode-inline-values-powershell) extension.
The default value of the `debug.openDebug` setting is now `openOnDebugBreak` so that on every breakpoint hit, VS Code will open the Debug view. The Debug view is also displayed on first session start.
As usual, the complete list of changes can be found in the [vscode-js-debug changelog](https://github.com/microsoft/vscode-js-debug/blob/main/CHANGELOG.md#changelog).
Based on [heuristics](https://github.com/microsoft/vscode/issues/57590#issuecomment-813616178), VS Code will show a notification that suggests opening the breakpoint diagnostic tool if it detects the user may be having trouble getting breakpoints to bind.
[Private class fields](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Classes/Private_class_fields) are now visible and can be inspected in the debugger.
You can now temporarily toggle the line numbers of a cell in the current session from the cell toolbar, or change the visibility of line numbers for all notebooks through the `notebook.lineNumbers` setting.
The cell toolbar position can be now customized per file type through the `notebook.cellToolbarLocation` setting. For example, you can have the cell toolbar on the right side for [GitHub Issue](https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-github-issue-notebooks) notebooks but have it on the left for Jupyter notebooks.
We implemented math support using an experimental notebook markup renders API, which is still in development. Our eventual goal with this API is to also allow extensions to extend the rendering of Markdown in notebooks.
The new `markdown.preview.typographer` setting lets you enabled smart quotes and simple [typographic replacements](https://github.com/markdown-it/markdown-it/blob/master/lib/rules_core/replacements.js) in the built-in Markdown preview.
When enabled, the new tabs view will only show by default when there are at least two terminals. For single terminals, the tab is "inlined" into the panel title like so:
* Double-clicking the empty space will create a new terminal.
* Double-clicking the sash will toggle the tabs view width between the "ideal" size that displays all the titles without truncating and a narrow view that shows only the icons.
* The tabs can be moved to the left side using the `terminal.integrated.tabs.location` setting.
Along with tabs, we have introduced the concept of **statuses** to the terminal. A terminal can have many statuses, each of which represents a state the terminal can be in temporarily, with the highest severity one being displayed next to the tab. Status icons appear to the right of the terminal title in the tabs view. On hover, details of the status and any associated actions are presented.
We have expanded the `walkthroughs` contribution for placing content on the Getting Started page to allow for Markdown in both step descriptions and step main content. Extension contributions to the Getting Started page are an experimental feature, and can be enabled with `"workbench.welcomePage.experimental.extensionContributions": true,`.
The short video belows show an example walkthrough to teach users about the [Luna Paint](https://marketplace.visualstudio.com/items?itemName=Tyriar.luna-paint) extension.
In this milestone, we added experimental support for custom hovers in the Activity bar and Panel. You can enable custom hovers using the setting `workbench.experimental.useCustomHover`.
As part of this release, we are previewing a new built-in extension, **Remote Repositories (RemoteHub)**, which allows you to instantly browse, search, edit, and commit to any GitHub repository directly from within VS Code without having to clone or have the repository locally. It is currently only available in the [Insiders](https://code.visualstudio.com/insiders/) edition of VS Code.
To get started, run the **Open Remote Repository...** command from the Command Palette. From there, you can paste in any GitHub URL, or choose to search for a specific repository or pull request.
Once you enter a URL or choose a repository or pull request, VS Code will open a new workspace for that repository. The remote status indicator, on the left side of the Status bar, shows the connected remote provider name, for example GitHub, for the remote repository.
* Clone the repository into a container - requires the [Remote - Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension
* Provides a familiar user interface similar to working on a local repository (*see "Limitations" below).
* **Explorer** - Open, copy, move, rename, and delete files and folders
* **Search** - Fast full-text search<sup>*</sup>
* **Source Control** - Stage and commit your changes, as well as many other source control actions
* **Timeline** view - See file history with diff support
* **Quick Open** - Quickly find files to open
* **Remote Indicator** - Shows the provider that the remote repository is connected to (for example, GitHub)
* Work on different branches simultaneously - each remote branch is treated like a separate worktree (in Git parlance), meaning that any changes you make are isolated to that branch. You don't need to stash your changes just to switch to a new branch in order to checkout a PR or start on a new work item. And when you go back to the previous branch, your changes will still be there.
* Install the [GitHub Pull Requests and Issues](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github) extension, and quickly view, explore, and checkout pull requests, view and start working on issues.
* Limited language intelligence - Many language servers don't yet understand this virtualized environment. TypeScript supports single file intelligence for remote repositories.
* Limited extension support - As with language servers, many extensions don't work with remote repositories. Extensions can opt-out and will not be activated for virtual workspaces. See the [Extension authoring section](#extension-authoring) below for more details.
* Search - Full-text search requires a pre-built index for exact text matching, otherwise it will fallback to GitHub's fuzzy default-branch only native search.
* Terminals - Not supported. Any terminals open will be on your local file system.
We are very excited for you to play with **Remote Repositories (RemoteHub)** and can't wait for your thoughts and feedback. We are just getting started on this journey, so expect the feature set to grow and the limitations to shrink as we continue development. We will also be expanding the set of supported providers. GitHub is just the first provider we are supporting, with Azure Repos coming soon.
This release continues to improve our support for the upcoming TypeScript 4.3 release. You can read more about the new language features and improvements in TypeScript 4.3 [on the TypeScript blog](https://devblogs.microsoft.com/typescript/announcing-typescript-4-3-beta/). Here are some of the editor improvements it enables:
* Import statement completions. This is like auto import, except you are typing in the import statement itself.
* JSDoc `@link` tag support.
To start using the TypeScript 4.3 nightly builds, just install the [TypeScript Nightly extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-typescript-next). Please share your feedback and let us know if you run into any bugs with TypeScript 4.3.
In last milestone's release notes, we shared our work on Workspace Trust specifically for extension authors. We made great progress this milestone for both the extension API and user experiences. That being said, Workspace Trust will remain disabled for this release, but we would love for you to try it out and provide feedback.
You can enable the feature with the following setting `security.workspace.trust.enabled`. Once enabled, you will see the following dialog when opening folders in VS Code.
This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the `security.workspace.trust.startupPrompt` setting.
Work continues on the [Remote Development extensions](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack), which allow you to use a container, remote machine, or the [Windows Subsystem for Linux](https://docs.microsoft.com/windows/wsl) (WSL) as a full-featured development environment.
You can learn about new extension features and bug fixes in the [Remote Development release notes](https://github.com/microsoft/vscode-docs/blob/main/remote-release-notes/v1_56.md).
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.
To learn about all the new features and updates, you can see the full [changelog for the 0.26.0](https://github.com/microsoft/vscode-pull-request-github/blob/main/CHANGELOG.md#0260) release of the extension.
The new [Remote Repositories](#remote-repositories-remotehub) extension lets you open a folder with content directly from GitHub. It does so by providing a [virtual file system](https://github.com/microsoft/vscode/blob/dc8bd9cd7e5231745549ac6218266c63271f48cd/src/vs/vscode.d.ts#L7038) and opening a workspace on it. Other extensions do the same. They serve content from ftp-servers, from cloud storage, or from databases and seamlessly provide these as files to the user in VS Code.
The virtual file system feature has existed for some time, however we have observed that not all extensions can support running in a **virtual workspace**, where the workspace files do not exist physically on disk. For this reason, we have added support for an extension to signal whether it supports running in a virtual workspaces or not. When an extension has opted-out, it will not be activated by VS Code for a virtual workspace and the user will not see errors from this extension.
The goal is that as many extensions as possible support running in a virtual workspace. However, this is not always possible, particularly when an extension is using components that assume that files are physically present. The [Virtual Workspaces guide](https://github.com/microsoft/vscode/wiki/Virtual-Workspaces) documents how an extension can support a virtual workspace.
**Call to Action**: Please check whether your extension can handle virtual workspaces, and set the `virtualWorkspaces` capability accordingly in your `package.json`.
There will be a transition period until extensions have adopted the new `virtualWorkspaces` property. Until then, we maintain an internal list for extensions that we think should have the `virtualWorkspaces` capability set to `false`. This was done based on an analysis whether the extensions is using the Node.js `fs` module and is therefore accessing the file system directly. However, the extension author is in a much better position to assess whether an extension supports the `virtualWorkspaces` capability. To track the adoption, we have created the following [tracking issue #122836](https://github.com/microsoft/vscode/issues/122836). If your extension is in the list and you have adopted the `virtualWorkspaces` capability, please add a comment in the above issue.
Ever since the webview API was first introduced, we've implemented webview using [Electron's webview tag](https://www.electronjs.org/docs/api/webview-tag). On the web however, VS Code's webviews are instead implemented using standard `<iframe>` elements since `<webview>` is not available.
We've been exploring migrating desktop versions of VS Code to use `<iframe>` backed webviews for a while, as this change will give extensions a more consistent webview environment between desktop and web. Migrating off of `<webview>` will also help with our Electron sandboxing efforts.
This iteration, we have switched the majority of webviews over to use iframes. The `<webview>` tag is now only used for webviews that enable the Find widget, and we plan on migrating them to use iframes as well after a bit more engineering work.
This change should not cause issues, however there are some corner cases where the behavior of `<iframe>` and `<webview>` elements differ. Be sure to give your extension a quick test pass to verify that everything works as expected.
If you've worked with webviews previously, you may remember that you had to use the **Developer: Open Webview Developer Tools** command to inspect the contents of your webview. This would open a new developer tools panel just for your webview.
You can also use the developer tools to evaluate expressions in a webview's context. After opening VS Code's dev tools with **Developer: Toggle Developer Tools**, open the console, and select the `active-frame` for your webview from the context selector.
The new `triggerKind` property on `CodeActionContext` tracks why Code Actions are being requested from a `CodeActionProvider`. The possible values of this property are:
Providers can use `triggerKind` to return different sets of results depending on how Code Actions are requested. For example, a refactoring Code Action provider that is triggered automatically may only return refactorings for the exact current selection in order to limit how often the Code Action lightbulb shows up. However when Code Actions are explicitly requested, the same provider may automatically expand the current selection to try to show all the refactorings that a user may be interested in at the current location.
Last milestone, we mentioned the work we had been doing on a feature called Workspace Trust. We asked extension authors to keep an eye on [issue #120251](https://github.com/microsoft/vscode/issues/120251) for updates and we continue to do so. The following information and updates can be found in that issue as well.
This milestone we moved the Workspace Trust extension API from proposed to stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.
You can declare your extension to provide complete or partial or no support in untrusted workspaces using the `untrustedWorkspaces` capability in `package.json`.
The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.
The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.
The third option is to declared `limited` support. There are three tools provided to you when you select the `limited` option.
First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using `restrictedConfigurations` array property in `untrustedWorkspaces` object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code [Workspace Configuration](https://code.visualstudio.com/api/references/vscode-api#WorkspaceConfiguration) API.
**Call to Action**: Please review the "Workspace Trust Extension Guide" in [issue #120251](https://github.com/microsoft/vscode/issues/120251) and set the `untrustedWorkspaces.supported` value as appropriate for your extension.
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/main/src/vs/vscode.proposed.d.ts) file into your project's source location.
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.
We added the `NotebookSerializer` API. It provides a simplified way to translate "bytes" into `NotebookData` and vice versa. When you implement this API, your notebook will get features like backup, revert, dirty-state, and others for free. We recommend extension authors adopt this new API and not use the previous content provider-based API.
The notebook controller API replaces the kernel provider API. Notebook controllers provide the execution engine of your notebook, which create the notebook output. Notebooks can provide multiple controllers or none and VS Code allows users to select controllers. In return, extensions are free to create, modify, and remove controllers as their domain model demands.
The `NotebookCellStatusBarItemProvider` API replaces the `createCellStatusBarItem` method. It enables extensions to contribute items with labels, icons, and commands, to the Status bar at the bottom of every cell editor. It follows the same provider pattern as many other VS Code extension APIs.
We intended to finalize a subset of the new testing APIs this month, however we focused on refinement and deferred finalization to next month, tracked in [issue #122208](https://github.com/microsoft/vscode/issues/122208). API changes made this iteration were primarily:
* The `TestProvider` was renamed to the `TestController` and its methods were renamed accordingly.
* The `TestItem`s are now managed objects called by `vscode.test.createTestItem`.
* Test results are now created through a standard `vscode.test.createTestResults` method, which can be called within or outside of `TestController.runTests`.
With these changes came a few additional features, such as the ability to display raw test output and for extensions to indicate errors in loading tests. We believe these changes provide a solid foundation for additional capabilities going forward and align more closely to our existing extension APIs.
We also created a [Test Adapter Converter](https://marketplace.visualstudio.com/items?itemName=ms-vscode.test-adapter-converter) extension that allows any adapter working with the existing [Test Explorer UI](https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-test-explorer) extension to automatically plug into native VS Code testing. The converter extension can be installed manually today, and soon it will integrate with the Test Explorer UI for a seamless migration path for existing users and adapters into native testing.
* Typed arrays, such as `UInt8Array`, serialize very inefficiently. This can cause performance issues when you need to transfer many megabytes of data.
* Sent typed arrays are not recreated as the correct type on the receiving side. If you send a `UInt8Array`, the receiver instead gets a generic object that has the data values of the `UInt8Array`.
While both of these issues are bugs, we also can't fix them without potentially breaking extensions that rely on the existing behavior. At the same time, there's zero reason a newly written extension would want the current confusing and inefficient behavior.
Therefore, we've decided to leave the existing behavior in place for existing extensions but opt new extensions into the more correct behavior. This is done by looking at the `engines` in your extension's `package.json`.
```json
"engines": {
"vscode": "^1.57.0",
}
```
If the extension targets VS Code 1.57+, then typed arrays should be recreated on the receiver side and the transfer of large typed arrays to and from webviews should be much more efficient.
Please test out this behavior and let us know if it either doesn't work as expect or causes unexpected regressions for your existing code.
### Exception breakpoints are better aligned with regular breakpoints
The `setExceptionBreakpoints` request can now optionally return an array of `Breakpoint`s similar to other `set*Breakpoints` requests. This allows clients to show validation error messages for individual exception breakpoints or filters. Starting with this release, VS Code shows these errors in the Breakpoints view.
### Restart request can now pick up debug configuration changes
The `restart` request now takes a new optional parameter `arguments`, where clients can pass the latest version of a launch or attach configuration. With this addition, a debug adapter can restart the session with up-to-date values from the debug configuration.
### Disconnect debugger and keep debuggee suspended
The `disconnect` request is used to end a debug session and to either continue execution of the debuggee or to terminate it. There is a new option to keep the debuggee in the suspended state after the debugger disconnects. This makes it possible to pick up debugging with a new session.
A debug adapter implementing this feature must announce its support with the `supportSuspendDebuggee` capability. A client can use the feature by passing a new optional argument `suspendDebuggee` to the `disconnect` request.
In this milestone, we finished the exploration to bundle Electron 12 into VS Code, thanks to everyone involved with testing and self-hosting on Insiders. This is a major Electron release and comes with Chromium 89.0.4389.114 and Node.js 14.16.0.
This milestone we continued to make the VS Code window ready for enabling Electron's [sandbox](https://www.electronjs.org/docs/tutorial/sandbox) and [context isolation](https://www.electronjs.org/docs/tutorial/context-isolation) features.
* We changed all of the environmental properties needed for a VS Code window to be accessible in a sandboxed renderer.
* We are exploring switching to `iframe` elements instead of `webview` for custom editors by selectively enabling the `iframe` in certain cases where possible.
* We were able to move some of the native module or Node.js requirements we have in the renderer to other processes or remove them entirely.
In desktop VS Code, webviews now use service workers to load local resources. Web versions of VS Code have always used service workers for this, but previously desktop VS Code was using an [Electron protocol](https://www.electronjs.org/docs/api/protocol).
Using service workers in the desktop version, lets us better align the behavior of webviews between desktop and web. It also helped us fix a few tricky bugs and let us delete around 1000 lines of code.
If your extension was using the `vscode-webview-resource:` protocol directly or hard coding other assumptions about resource URIs, it may no longer work.
Instead, make sure you always use `.asWebviewUri` to create URIs for resources. Also remember that the format of the returned URI may chance in the future.
The upcoming TypeScript 4.3 release a new [override keyword](https://github.com/microsoft/TypeScript/issues/2000) which tells the compiler that a method in a subclass overrides a method in its superclass. There's also a new `--noImplicitOverride` flag that enforces that all methods that override a method from a superclass must use the `override` keyword:
* It is an error to try to override a method that does not exist on the base class. This can help catch errors caused by renaming a method in a base class but forgetting to update the method name in the subclasses.
This iteration we adopted the override keyword in our codebase and also enabled `--noImplicitOverride` for both core VS Code and all builtin extensions. While we automated the majority of this work, the change did help us catch a few cases where our code was incorrectly re-declaring a property or had unclear inheritance patterns.
This new strictness rule should also help us catch some common programming mistakes in the future.
We have updated our [Windows Package Manager](https://docs.microsoft.com/windows/package-manager/) publishing pipeline to publish our user and system installers for `arm64`, and to adopt the [v1 package manifest schema](https://github.com/microsoft/winget-cli/blob/master/doc/ManifestSpecv1.0.md), allowing us to consolidate the user and system installers for `x86`, `x64` and `arm64` into a single manifest. Users can pick between the user and system installers using the `--scope` parameter when [installing](https://docs.microsoft.com/windows/package-manager/winget/install) a package or using the [winget CLI settings](https://aka.ms/winget-settings#scope).
The VS Code [introductory videos](https://code.visualstudio.com/docs/getstarted/introvideos) have been updated. The videos range from [Getting Started](https://code.visualstudio.com/docs/introvideos/basics) and [Using extensions](https://code.visualstudio.com/docs/introvideos/extend) to VS Code features like [Debugging](https://code.visualstudio.com/docs/introvideos/debugging) and [Version Control](https://code.visualstudio.com/docs/introvideos/versioncontrol).
The [C++ extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools) team has created a set of [introductory videos](https://code.visualstudio.com/docs/cpp/introvideos-cpp) explaining how to configure IntelliSense, build, and debug your C++ projects.
### The Story and Technology Behind VS Code
You can read about the history and underlying technology of VS Code in [this interview](https://www.git-tower.com/blog/developing-for-the-desktop-vscode/) with VS Code engineer, [Ben Pasero](https://twitter.com/benjaminpasero). Ben talks about the early days of VS Code and what it's like to use Electron as an application framework enabling VS Code run on macOS, Windows, and Linux.
## Partner extensions
### Azure Machine Learning
The [Azure Machine Learning](https://marketplace.visualstudio.com/items?itemName=ms-toolsai.vscode-ai) extension enables you to create and manage powerful cloud computing resources for your machine learning workflows. With its remote capabilities, you can seamlessly [connect to your compute resources](https://techcommunity.microsoft.com/t5/azure-ai/supercharge-azure-ml-code-development-with-new-vs-code/ba-p/2260129) in a secure, auditable, and compliant manner.
* [108559](https://github.com/microsoft/vscode/issues/108559): RunInTerminal doesn't use the specified integrated terminal from workspace settings bug
* [118282](https://github.com/microsoft/vscode/issues/118282): Debugger Step Over into skipFiles
* [118731](https://github.com/microsoft/vscode/issues/118731): Investigate how to avoid Safari's popup-blocker when opening browser windows and tabs asynchronously
* [119340](https://github.com/microsoft/vscode/issues/119340): Run Without Debug never terminates if uncaught exceptions breakpoint is enabled
* [121347](https://github.com/microsoft/vscode/issues/121347): File gets garbled characters when restored from backup
* [119059](https://github.com/microsoft/vscode/issues/119059): Custom text editors: backups open 2 editors when restoring
* [120245](https://github.com/microsoft/vscode/issues/120245): CSS: `!important` completion is broken
* [120277](https://github.com/microsoft/vscode/issues/120277): The horizontal scroll bar in the Find in Files pane is too small and scrolls the wrong way
* [@alexmyczko (Alex Myczko)](https://github.com/alexmyczko): Improve debian control description [PR #119160](https://github.com/microsoft/vscode/pull/119160)
* [@aliasliao (Liao Jinyuan)](https://github.com/aliasliao): fix emmet issue where wrong suggestions is promoted in html file [PR #120480](https://github.com/microsoft/vscode/pull/120480)
* [@arnobl (arno)](https://github.com/arnobl): fix(notebook): redo cell creation does not re-select the cell [PR #120086](https://github.com/microsoft/vscode/pull/120086)
* [@awilkins (Adrian Wilkins)](https://github.com/awilkins): Implement selection paste for integrated terminal on Linux [PR #108397](https://github.com/microsoft/vscode/pull/108397)
* [@benmccann (Ben McCann)](https://github.com/benmccann): Fix issue number in comment [PR #121758](https://github.com/microsoft/vscode/pull/121758)
* [themes] Fix JSON formatting in High Contrast Black default theme [PR #120761](https://github.com/microsoft/vscode/pull/120761)
* [themes] Fix JSON formatting in High Contrast Black default theme (2) [PR #120815](https://github.com/microsoft/vscode/pull/120815)
* [themes] Fix JSON formatting in High Contrast Black default theme (3) [PR #120841](https://github.com/microsoft/vscode/pull/120841)
* [@conwnet (netcon)](https://github.com/conwnet): fix: only add readonly attribute to textarea dom when editor is readonly [PR #120503](https://github.com/microsoft/vscode/pull/120503)
* fix #120485 hide `Open Timeline` from Explorer context menu when there are no timeline providers [PR #120497](https://github.com/microsoft/vscode/pull/120497)
* fix-120578 don't offer callstack step-in/over/out when not stopped [PR #120581](https://github.com/microsoft/vscode/pull/120581)
* fix #121509 documentation error for two API command results [PR #121511](https://github.com/microsoft/vscode/pull/121511)
* Fixes simple browser icons are broken in firefox [PR #120275](https://github.com/microsoft/vscode/pull/120275)
* Fixes horizontal scrollbar is too narrow in split settings editor JSON [PR #121027](https://github.com/microsoft/vscode/pull/121027)
* Fix regression cannot preview image with special characters '#', '%' or '?' [PR #121874](https://github.com/microsoft/vscode/pull/121874)
* [@Jolg42 (Joël Galeran)](https://github.com/Jolg42): Refactor npm extension to only use npm [PR #120317](https://github.com/microsoft/vscode/pull/120317)
* [@plainerman (Michael Plainer)](https://github.com/plainerman): Add support to deactivate auto-updating disabled extensions [PR #113155](https://github.com/microsoft/vscode/pull/113155)
* [@PooyaZv (Pooya Vakeely)](https://github.com/PooyaZv): Add cuda-cpp lang id, grammar and problem matchers [PR #119444](https://github.com/microsoft/vscode/pull/119444)
* [@qchateau (Quentin Chateau)](https://github.com/qchateau): format modified: format lines with whitespace changes [PR #119021](https://github.com/microsoft/vscode/pull/119021)
* [@sdegutis (Steven Degutis)](https://github.com/sdegutis): Make error message clearer [PR #121339](https://github.com/microsoft/vscode/pull/121339)
* [@sokolovstas (Stanislav)](https://github.com/sokolovstas): Fix file location pattern in eslint-stylish problem matcher [PR #117576](https://github.com/microsoft/vscode/pull/117576)
* [@solomatov (Konstantin Solomatov)](https://github.com/solomatov): Terminate in case of ext host IPC timeout [PR #122399](https://github.com/microsoft/vscode/pull/122399)
* [@stoyannk (Stoyan Nikolov)](https://github.com/stoyannk): Fixed wrong variable name shadowing that caused Profiles for extensio… [PR #120054](https://github.com/microsoft/vscode/pull/120054)
* [@timmaffett (Tim Maffett)](https://github.com/timmaffett): Fixed and extended Debug Console support for most ANSI SGR codes [PR #120891](https://github.com/microsoft/vscode/pull/120891)
* [@vinku](https://github.com/vinku): Emmet: Select next/previous item does not work with script tag. [PR #118842](https://github.com/microsoft/vscode/pull/118842)
* [@yannickowow (Yanis HAMITI)](https://github.com/yannickowow): Show current DataBreakpoint access type in "Breakpoints" view (#119588) [PR #119817](https://github.com/microsoft/vscode/pull/119817)
* [@vadimcn](https://github.com/vadimcn): Add a direct reference to JSON schema [PR #185](https://github.com/microsoft/debug-adapter-protocol/pull/185)
* [@noah-vdv (Noah van der Veer)](https://github.com/noah-vdv): fix 'orther' typo on line 162 [PR #255](https://github.com/microsoft/vscode-generator-code/pull/255)
