Extension authoring · code.visualstudio.com

Update 1.60.1: The update addresses these issues.

Update 1.60.2: The update addresses these issues.

Downloads: Windows: x64 Arm64 | Mac: Universal Intel silicon | Linux: deb rpm tarball Arm snap


Welcome to the August 2021 release of Visual Studio Code. There are many updates in this version that we hope you will like, some of the key highlights include:

If you'd like to read these release notes online, go to Updates on code.visualstudio.com.

Join us live at the VS Code team's livestream on Thursday, September 2 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 build and try the latest updates as soon as they are available.

Workbench

Automatic language detection

Last release, we introduced an experimental feature for untitled files that would automatically set the language mode for the file based on the contents. The automatic language detection feature uses machine learning to guess the language and the machine learning model runs entirely local on your machine. The model is powered by the open-source ML library, Tensorflow.js, and the ML model from Guesslang by GitHub user @yoeo.

This release we are enabling automatic language detection by default and also expanding detection to include files that don't have a file extension. In Notebooks, we provide an easy way to ask for language detection using the language picker.

We added this feature because we found that some new users of VS Code didn't know how to set the language mode and didn't know that this is needed in order to get VS Code's rich feature set (language colorization and extension recommendations). Enabling new users to quickly see the language features and extensions available for VS Code helps them as they ramp up on the editor.

In addition, power users who use untitled text editors as a scratch pad, no longer need to explicitly set the language mode, which we hope will streamline their workflow.

Below are several fun scenarios enabled by automatic language detection.

Grab an example from online and paste it in an untitled editor:

Theme: Panda Theme

"Pipe into code" language detection (showing off detection of extension-less files):

Theme: Panda Theme

Auto detect option in the Notebooks language picker:

Theme: Panda Theme

Terminal editor confirmation dialog

The dialog presented when closing a terminal editor with running child processes is now specific for the terminal editor and will no longer offer a way to "Save" the terminal.

Terminal editor confirmation dialog

Keep editors open instead of closing when they fail to restore

Previously, when an editor failed to restore after reload of the window or restart of the application, the editor would automatically close until an editor was found that successfully loads. This behavior led to frustrating results, where a carefully created editor layout would go away due to editors closing.

With this release, an editor that was once successfully opened will not close, even if it fails to restore. The editor indicates the problem and offers to retry the operation:

Keep editors open and offer to Try Again

Syntax highlighting of codeblocks in the Settings editor

Fenced code blocks in setting descriptions are now syntax highlighted:

Syntax highlighting of TypeScript code in the Settings editor

Open Settings editor to the side

It's now possible to open the Settings editor in a side group by configuring a keybinding using the openToSide argument.

The underscore is now at the bottom of the cell's bounds

Faster reconnection after reloading the window

Previously, when reloading a window, it could take up to 300 ms to parse the state of a terminal's buffer and there was also the possibility of corruption. For several busy terminals, this can quickly add up! To fix this, the method of restoring the buffer has changed from recording a large number of recent raw terminal events on the pty host to maintaining a headless terminal frontend on the pty host and writing all data to that.

This approach brings several benefits:

  • The amount of scrollback to restore can be fine-tuned. The default is now 100, which is a good balance between speed and the amount of data. The scrollback amount can be changed with the terminal.integrated.persistentSessionScrollback setting.
  • Thanks to xterm.js' fast parser, this should have minimal impact on CPU usage and reduce overall memory usage on the pty host.
  • Terminal modes are now restored explicitly that could potentially get missed before and cause buffer corruption.
  • There is no longer the need to replay costly resize events as the terminal's buffer is always in sync with its size.
  • Since the restore is relatively quick, it's all handled in a single frame. This means that precious CPU time isn't wasted on rendering the partially restored terminal and slowing things down further.

How much of a speedup this new implementation provides depends on many factors, like the number of terminals, hardware, terminal buffer size, and what was happening in the terminal. A rough estimate of restoring a full terminal buffer should yield an approximate speedup of 5-10x.

We also published the new xterm-headless package on npm, so you can use this work in your own project.

Debugging

Set Value in WATCH view

It is now possible to set the value of a watched expression in the WATCH view using the Set Value action in the context menu.

Shows WATCH view with the Set Value action selected in the context menu

Debug extensions have to opt into this feature in order for Set Value to be available. For now, the JS-debug, C#, and C++ extensions support this, but we expect other debug extensions to follow soon.

Minor UI improvements

  • VS Code now detects links for values also in the VARIABLES view, WATCH view, and Debug hover. When a variable's value is a link, this will make it easier to follow that link by clicking on it.

  • When starting another instance of a debug session that is already running, there is now a modal confirmation dialog to prevent accidentally starting two sessions.

  • Clicking on a disabled breakpoint in the editor's breakpoint gutter now enables the breakpoint instead of removing it.

  • When a debug session is active, the Run To Line action is now available in the editor's breakpoint gutter context menu:

New settings

  • If you want to avoid accidentally closing the window during a debug session, you can enable the new setting debug.confirmOnExit. With this set to always, you will be prompted to confirm that you want to stop the debug session when closing the window.

    Confirm quit while debugging

  • A new setting debug.console.acceptSuggestionOnEnter controls whether suggestions should be accepted on Enter in the Debug Console. Enter is also used to evaluate whatever is typed in the Debug Console, so this option gives users better control over what happens when pressing Enter.

JavaScript debugging

Legacy node debuggers are gone

VS Code has long included a built-in Node.js debugger, and published a separate Chrome debugger. Last year we introduced a new debugger for Node.js and Chrome, and since VS Code 1.47 (July 2020) it has been the default, with an 'opt out' option.

With this release, the old debuggers have been removed from the product and marked as deprecated on the Marketplace. If you're among the majority of VS Code users who didn't opt out of the new JavaScript debugger, nothing will change for you.

If you require the old debuggers—to debug Node.js 6 programs, for example—you can install the [Deprecated] Node Debug or [Deprecated] Debugger for Chrome extension and use the legacy-node or legacy-chrome launch types, respectively.

Improved stepping in async functions and Node.js internals

You can set the debugger's skipFiles to avoid stepping into certain code, including Node.js internals, which can often be hit when stepping around async functions.

However, Node.js does not always exhibit correct behavior when dealing with "blackboxed" scripts, so this iteration we've introduced "synthetic blackboxing" in the debugger. This should result in significantly improved reliability when working with Node.js programs, particularly when stepping into async functions.

In our next release, we plan to make the debugger skip Node.js internals by default.

Installer

Register VS Code for supported file types by default

Windows 11 introduces a new File Explorer context menu that puts Open With to the top of the menu, grouped with Open. The update makes it easier to find all available editors and change defaults.

Following the new best practices, VS Code's checkbox Register VS Code to be the editor for associated file types will now be checked on by default during Windows installation. We also reviewed the list of associated file types and expanded it to include more of the frequently opened file types.

Microsoft Store on Windows 11

With the upcoming Windows 11, the new Microsoft store can support more traditional application types and installers. If you are already testing Windows 11 via the Windows Insiders program, you can now install the latest release of VS Code today by searching for it in the store. Once installed, you will have the same VS Code that is available as a user install from our website and updates will be handled in-app, just like they are today.

Notebooks

Links between Markdown cells

Notebooks now support links between Markdown cells:

You can create a link to a header in a Markdown cell using:

new Uint8Array([72, 101, 108, 108, 111, 32, 67, 111, 100, 101, 33]);

That data is 11 bytes long. The old implementation would then convert the binary data to a JSON string:

"javascript.suggestionActions.enabled": false

For more comprehensive checking, try enabling full semantic checking in your JavaScript code. Not only can this help catch more errors, it also enables several helpful Quick Fixes.

typescript.tsserver.useSyntaxServer

The new typescript.tsserver.useSyntaxServer setting allows you to control if TypeScript launches a dedicated server to quickly handle syntax-related operations, such as computing code folding. It replaces the now deprecated typescript.tsserver.useSeparateSyntaxServer setting.

Possible values are:

  • auto - Spawn both a full server and a lighter weight server dedicated to syntax operations. The syntax server is used to speed up syntax operations such as code folding and provide IntelliSense while projects are loading. (Default)
  • always - Use a lighter weight syntax server to handle all IntelliSense operations. This syntax server can only provide IntelliSense for opened files.
  • never - Don't use a dedicated syntax server. Use a single server to handle all IntelliSense operations.

Preview features

Locked editor groups

With the introduction of terminals in the editor area, we received reports from users who were frustrated that a terminal editor would be replaced with a file editor too easily or by accident. By default, files will always open in the active editor group and thus, even when a terminal was active, a file would open and hide the terminal.

Locked editor groups provide a new way of handling this issue, not only for terminals but for any editor. If you have more than one editor group opened, you can now lock it, either using one of the new commands or from the "..." overflow menu:

Lock Group action on the editor context menu

Locked groups behave differently than unlocked groups:

  • New editors will not open in a locked group unless explicitly moved there by the user (for example, via drag and drop).
  • If an editor skips a locked group for opening, it will either open in the most recently used unlocked group or create a new group to the side of the locked one.
  • The locked state of an editor group is persisted and restored across restarts.
  • You can lock empty groups as well allowing for a more stable editor layout.
  • A locked group is indicated by a lock icon in the action toolbar (top right).

Locked editor group layout with lock icon

See the following demo of how locked editor groups behave in action. Even though the Markdown preview is active, new files will open in the left editor group:

The commands added for this feature are:

  • workbench.action.experimentalLockEditorGroup
  • workbench.action.experimentalUnlockEditorGroup
  • workbench.action.experimentalToggleEditorGroupLock

A new context key activeEditorGroupLocked is available to conditionally bind commands depending on the locked state of a group.

Note: The associated setting and commands are experimental until we have finalized the design of locked editor groups. We want your feedback on this new feature, so please do not hesitate to report issues.

Auto-lock an editor group

Building on top of the new locked editor groups concept, the new workbench.editor.experimentalAutoLockGroups setting allows you to select editors that should lock a group automatically when they open. This only applies when the editor is the first to open in an otherwise empty or new group.

Terminals are configured by default to cause a new group to lock automatically. In the short video below, even though the terminal is active, the selected file from the terminal will open in the left editor group:

If you want Markdown previews to lock a group automatically, you can add mainThreadWebview-markdown.preview: true to the experimentalAutoLockGroups setting.

In the next milestones, we will work on improving the settings UX to be able to pick editors without having to know their identifiers. The associated setting and commands are experimental until we have finalized the design of locked editor groups. Again we would like your feedback.

Quotes support in the "Search by file name" Quick Pick

This iteration, we have added the ability to exclude fuzzy search results from the "Search by file name" Quick Pick (⌘P (Windows, Linux Ctrl+P)) by placing the search string in quotes.

Scenarios where this shines:

When a query is only a few characters:

If you want to reduce the "clutter" of the results:

We like this quoting experience and it feels intuitive since most search engines use a similar mechanism, but we'd like your feedback. We are also considering other approaches discussed in issue #131431.

Contributions to extensions

Jupyter

Run By Line

VS Code now supports the Run By Line feature in Jupyter notebooks. This is a simple debug mode that lets you execute the code of a cell line by line. To try it out, make sure that you have ipykernel v6+ installed as your selected kernel, then select the Run By Line button.

Debugging

There is also experimental support for debugging Jupyter notebooks using the full debug features of VS Code. To try it out, make sure you have ipykernel v6+ installed as your selected kernel, set "jupyter.experimental.debugging": true, set a breakpoint, and select the Debug Cell command.

Jupyter Keymap

We extracted the Jupyter classic keybindings to a separate Jupyter Keymap extension, which you can disable if you prefer to use another set of notebook keybindings from the Marketplace.

Python

Revamped testing interface

Thanks to the new testing API, the Python extension has revamped its testing features. You can now enjoy a more stable experience for test discovery, navigation, and status rendering, as well as new features such as search tests, run a selection of tests, rerun last executed test, and more!

Running tests with the new Python Test Explorer

Run and debug Python files in the terminal from the editor

You can now run and debug your Python files in the terminal directly from the editor with the Python extension.

GitHub Pull Requests and Issues

The much requested ability to expand and collapse all comments in the GitHub Pull Requests and Issues extension is now available. All comments can be expanded and collapsed via the commands GitHub Pull Requests: Expand All Comments and GitHub Pull Requests: Collapse All Comments. There is also a setting githubPullRequests.commentExpandState to control the expand collapse state. Finally, you can also collapse all comments from within the commenting UI:

Collapse all pull request comments button

To learn about all the new features and updates, you can see the full changelog for the 0.30.0 release of the extension.

Web extensions

When VS Code is running in a browser, extensions are loaded into an extension host also running in the browser. The "web extension host" is constrained by the browser and extensions do not have access to the local file system or platform features. To help extension authors update their extensions to support running in VS Code for the web, there is now a Web Extensions authoring guide. Here you will learn which types of extensions work best on the web, how to access the VS Code APIs, and work with virtual file systems.

Along with the web extension guide, the yo code extension generator now has an option to scaffold a Web Extension, and also includes support for the @vscode/test-web module to test web extensions from the command line.

If you haven't seen Visual Studio Code for the Web in action, you can press '.' (the period key) in the <> Code tab of a GitHub repository and you will launch a web-based version of VS Code to browse and edit the source code.

Short title for commands

The commands contribution point allows extensions to define UI-properties for commands, like title, category, or icon. Menus, on the other hand, are "places" that display commands and menus may present some or all of the command's UI-properties. For instance, some menus render only icons while others render titles or category plus title. As an extension author, it can be hard to come up with a command title that works equally well for global and local menus. For example, the Command Palette can display more words than a context menu.

To allow for different titles, there is a new shortTitle property. It allows commands to provide a shorter title that works well depending on the UI, such as Notebook: Clear All Cell Output in the Command Palette and shorter Clear All in the notebook toolbar.

Application host added to environment namespace

The .env namespace now includes the application host appHost property. appHost allows extension developers to determine the environment VS Code is hosted in. Examples include desktop, GitHub Codespaces, github.dev, and vscode.dev.

RendererContext.workspace.isTrusted for notebook renderers

The new workspace.isTrusted property on the context object passed to notebook renderers lets extension authors check if the current workspace is trusted or not:

">PR #156
            

Read the original on code.visualstudio.com ↗