Vscode New version Changes

 

Resizing columns in Keyboard Shortcuts editor

The Keyboard Shortcuts editor is now refactored to use the new table widget, allowing users to resize the columns in the editor.

Extension management improvements

• VS Code now detects extensions installed/uninstalled through the VS Code CLI. Extensions can be activated/de-activated in the active window (instance) and will be correctly displayed in the Extensions view.

• VS Code now shows the set of extensions included in an extension that sets the extensionPack property in a separate Extension Pack tab even when the extension is not categorized as Extension Packs.

Theme: GitHub Light Theme

Negative text filtering in Problems view

You can now filter problems that do not contain specific text from the Problems view by prepending ! to the filter text.

Reporting Marketplace issues

Last month we highlighted that there's a new public repository for issues related to the Extension Marketplace. Now, VS Code's issue reporter supports creating issues in this repository.

Configure tree hover delay

The hover delay for extension contributed tree views can now be configured with workbench.hover.delay.

Emmet

The emmet.extensionsPath setting now takes in only string arrays, and can be directly edited in the Settings editor.

Search in Open Editors

You can now toggle the Search Only in Open Editors checkbox in a workspace search to change from searching the entire workspace to only searching in files that have been opened in editor tabs. This previously was enabled via an opt-in, this iteration we've enhanced the behavior with files that have not yet been loaded in the VS Code session and enabled it by default.

Control the font size of the Source Control input

You can now change the font size of the Source Control input via the new scm.inputFontSize setting.

Integrated Terminal

Terminal profiles

The terminal now supports defined profiles, which appear in the terminal's dropdown, to conveniently launch non-default shells:

VS Code will automatically detect and surface some of the more commonly used shells through this menu, but they can also be configured using the terminal.integrated.profiles.<platform> setting. With this setting, it's possible to add new profiles, change existing profiles and remove default profiles. For example:

"terminal.integrated.profiles.windows": {
  // Add a PowerShell profile that doesn't run the profile
  "PowerShell (No Profile)": {
      // Some sources are available which auto detect complex cases
      "source": "PowerShell",
      "args": ["-NoProfile"],
      // Name the terminal "PowerShell (No Profile)" to differentiate it
      "overrideName": true
  },
  // Remove the builtin Git Bash profile
  "Git Bash": null,
  // Add a Cygwin profile
  "Cygwin": {
    "path": "C:\\cygwin64\\bin\\bash.exe",
    "args": ["--login"]
  }
}

The recommended way to initially add a profile is via the Select Default Profile command, which allows creating profiles based on either an existing profile or other detected shells.

Auto detected WSL profiles and improved defaults on Windows

Along with the new profiles feature, we now auto detect WSL profiles and show them in the list by default. This can be turned off with the terminal.integrated.useWslProfiles setting.

Cygwin is also now auto detected and exposed in the Select Default Profile command and Git Bash will run as a login shell (running ~/.bash_profile).

WebGL renderer is the new default

The terminal first got the experimental WebGL renderer back in the November 2019 release, which based our calculations at the time could increase performance by up to 900% and by even more if your environment had issues with rendering using a standard 2D canvas context.

Since then, the WebGL renderer has gradually improved in stability and had its feature gap closed. We decided now is as good a time as any to make the transition, but will be watching for any issue reports.

As part of this work we also added some fallback logic. When "terminal.integrated.rendererType": "auto", the following happens:

1. The WebGL renderer will try to start up.
2. If it fails, for example due to lack of OS/browser support:
   • The canvas renderer will be enabled and the time it takes to render a frame will start to be measured.
3. If the first 20 frames are rendering slowly, for example if there are hardware issues or GPU rendering is disabled:
   • The DOM renderer will be enabled.

In the next release, we plan on removing the rendererType setting all together in favor of a much more understandable "terminal.integrated.gpuAcceleration": "auto" | "on" | "off".

Seamless terminal relaunching

Last release, we introduced automatic relaunching of terminals when an extension wants to change the environment. This release will now prevent the flickering that was caused before when the relaunch occurs. If the output of the new terminal is identical to the last, there is no feedback or distractions caused by the relaunch.

There is also a new setting to disable this automatic relaunching all together terminal.integrated.environmentChangesRelaunch.

Debugging

Improvements to breakpoints

Inline menu to edit conditions and hit count

We now show an inline menu for editing conditions and hit counts for function breakpoints. Previously the inline edit button would choose automatically what condition to edit. Now, the menu should make the flow easier and give more control to the user.

Support for all access types of data breakpoints

Now VS Code's generic debugger UI supports all data breakpoint access types defined in the Debug Adapter Protocol as context menu actions in the VARIABLES view:

• Break on Value Read: breakpoint will be hit every time a variable gets read.
• Break on Value Change: breakpoint will be hit every time a variable gets changed (this action was previously available).
• Break on Value Access: breakpoint will be hit every time a variable is read or changed.

Please note that debug extensions have to opt into this feature in order to make individual actions available. For now, only the Mock Debug extension has (simulated) support for all three access types, but we expect other debug extensions to follow soon - such as the Java extension.

Clearing a terminal before launching a debuggee

Some debug extensions allow you to launch debuggees in VS Code's Integrated Terminal. In order to keep the number of Integrated Terminals small, VS Code tries to reuse a terminal if it is not blocked by a still running command. A consequence of this approach is that previous commands and program output will remain visible in the terminal, which is sometimes confusing.

In this release, we've introduced a new feature to automatically clear the Integrated Terminal before starting a new debug session. The feature is controlled by the new setting debug.terminal.clearBeforeReusing.

JavaScript debugging

As usual, the complete list of changes can be found in the vscode-js-debug changelog.

Start Debugging and Stop on Entry

When we moved to our new debugger, last year, the Debug: Start Debugging and Stop on Entry was left behind. It once again works, and requests the debugger to pause on the first line of your Node.js program. By default it is bound to F10.

Improved handling of symbolic links

Debugging Node.js programs with symbolic links can require special flags to be passed to the program. Without these flags, breakpoints remained unbound, and it was hard to figure out what was going wrong. Now, the debugger will automatically detect these cases and provide a helpful notification.