🚀 Get in VS Code!

September 2017 (version 1.17)

Update 1.17.2: The update addresses these issues.

Update 1.17.1: The update addresses these issues.

Downloads: Windows | Mac | Linux 64-bit: .tar.gz .deb .rpm | Linux 32-bit: .tar.gz .deb .rpm

Welcome to the September 2017 release of Visual Studio Code. There are a number of significant 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.
You can also check out this 1.17 release highlights video from Cloud Developer Advocate Brian Clark.

The release notes are arranged in the following sections related to VS Code focus areas. Here are some further updates:

  • Workbench - Better macOS native tabs support, new editor label formats.
  • Editor - Snippet transforms, more Emmet preferences, optimized history navigation.
  • Languages - TypeScript 2.5.3, Extract Method triggers rename, language support in Markdown code blocks.
  • Extension Authoring - macOS Touch Bar support, styled completions and signature help text.

Insiders: Want to see 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

macOS Touch Bar support

There is now support for showing actions in the macOS Touch Bar. Out of the box we add actions to navigate in editor history as well as the full debug tool bar to control the debugger:

Touch Bar

Extensions can add commands to the Touch Bar as well via the new touchBar menu identifier. See below under Extension Authoring for more details.

Better macOS native window tabs support

You can enable native window tabs on macOS (Sierra) with the "window.nativeTabs": true setting. In this milestone, we made working with native tabs easier.

Native Window Tabs

For one, you will now find a "+" action next to the last tab to open a new window as tab. We also added the typical actions to the window menu for managing tabs.

Note: Native tabs on macOS High Sierra (10.13) are currently only partially supported. We are working on a fix, stay tuned!

We've updated the VS Code logo and colors, orange for the stable release and green for Insiders.

Release Stable Insiders
macOS / Linux macOS stable Windows stable
Windows macOS insiders Windows insiders

Note: Depending on your platform, you may still see the earlier logo due to operating system caching of the application icon.

Better --wait support

VS Code can be started with the --wait argument from the command line to wait until the instance that opens is closed. In this milestone, we made this feature more powerful by also terminating the calling process when all of the editors are closed that got opened. As a consequence, you can now use --wait with instances that are already opened, making this a much faster experience.

Better --wait support

Note: By default, we will now reuse any opened instance. To avoid that, add the -n argument to the command line.

New features around file encoding

It is now possible to configure the files.encoding as well as files.autoGuessEncoding setting per language. VS Code also now supports CP 850 and CP 865 encoding.

New setting to control editor labels

A new setting, workbench.editor.labelFormat, adjusts the default label for editors. Possible values are short, medium, long and default. By default, editors will only show information about the file path when multiple editors with the same name are opened. If any of the other options is used, the editor label will always show path information.

Label Format

${workspaceFolder} in launch.json and tasks.json

We have introduced a new substitution variable ${workspaceFolder}. This variable will get substituted to the absolute path of the workspace folder containing the appropriate launch.json or tasks.json. This has the same effect as the previous ${workspaceRoot}, however we felt like the old name was not specific enough for the upcoming multi-root workspace scenarios. We are deprecating ${workspaceRoot}, though we will still support substituting it for backwards compatibility. More about variable substitution can be found here.

QuickOpen uses ripgrep

QuickOpen (⌘P (Windows, Linux Ctrl+P)) now uses ripgrep to retrieve the full list of file names before applying the user's input filter. Windows users should see improved performance on large folders getting them on par with Linux and macOS which were previously using find to boost listing file names.

Editor

Folding regions

Folding now supports region markers. Markers are defined by the language in the language configuration.

The following languages currently have markers defined:

  • TypeScript/JavaScript: //#region and //#endregion and //region and //endregion
  • C#: #region and #endregion
  • C/C++: #pragma region and #pragma endregion
  • F#: //#region and //#endregion
  • PowerShell: #region and #endregion
  • VB: #Region and #End Region

Region Folding

Each language also has snippets available for the markers. Type '#' and invoke code completion to see them.

To have region markers configured for your language, contact the language extension provider.

Folding in off-side languages

In languages that follow the off-side rule for code blocks, empty lines belong to the next folding region.

Off-side Folding

The setting is configured in the language configuration and is enabled for the following languages:

Python, Yaml, Pug, Markdown, Clojure, CoffeeScript, FSharp.

Snippet selector

The snippet picker dropdown shown by the Insert Snippet command now displays snippets in two groups, User Snippets and Extension Snippets. User-defined snippets are listed on top to give you quick access to your favorite snippets.

Snippet Buckets

Snippet transforms

The VS Code snippet engine now supports variable transformations. Transformations can change the value of a variable before inserting it. The format is var_name/regular_expression/format_string/options. The sample below is a snippet that creates a public Java class whose name is derived from the filename.

  "Public Class": {
    "prefix": "pclass",
    "body": [
      "public class ${1:${TM_FILENAME/(.*)\\.java/${1:/capitalize}/}} {",
      "\tpublic $1 (${2:params}) {",
      "\t\t$0",
      "\t}",
      "}"
    ],
    "description": "New public class"
  }

The new part is this: ${TM_FILENAME/(.*)\\.java/${1:/capitalize}/} and this is what it does:

  1. Resolve the value for TM_FILENAME, for example myClass.java.
  2. Use the regular expression /(.*)\\.java to create a matching group for everything that precedes the .java ending, for example myClass.
  3. Take the value of the first matching group, ensure it start with capital letters (/capitalize), and insert it (MyClass).

To learn more, check out our snippet grammar to see what you can do and then get creative.

Lightbulb improvements

  • The new editor.lightbulb.enabled setting enables or disables the Code Action light bulb in the editor. The default value is true.
  • The Code Action menu now selects the first entry by default making it easier to run.

Improved history navigation

VS Code has commands to navigate within the editor history (workbench.action.navigateBack, workbench.action.navigateForward), either across or within files. During this milestone, we tweaked the experience to produce less unwanted stops in history:

  • We now require a minimum distance of 10 lines from one selection to another to add a new entry to history (previously we required a distance of 5 lines).
  • Navigating less than 10 lines replaces the last history stop within the file with that location and thus avoids introducing unwanted stops.

In addition, we no longer center the selection vertically when navigating unless the selection is outside of the view. This makes it easier to stay in context while navigating around.

Coloring of warning squiggles

You can now use a different color for warning squiggles to differentiate them from information:

Snippet Buckets

Emmet preferences

We're continuing to add support for more Emmet Preferences in Emmet 2.0. In addition to the preferences we added in the last release, we now have:

  • bem.elementSeparator
  • bem.modifierSeparator
  • filter.commentBefore
  • filter.commentTrigger
  • filter.commentAfter

The format for the filter.commentAfter preference is different and simpler in Emmet 2.0.

For example, instead of the older format

"emmet.preferences": {
    "filter.commentAfter": "\n<!-- /<%= attr('id', '#') %><%= attr('class', '.') %> -->"
}

you would use

"emmet.preferences": {
    "filter.commentAfter": "\n<!-- /[#ID][.CLASS] -->"
}

Integrated Terminal

New rendering engine

The integrated terminal is now using a new canvas-based rendering engine which renders approximately 5 to 45 times faster, depending on the situation. This change reduces the input latency, power usage, and increases the frame rate of the terminal significantly.

60 FPS is now possible in the terminal

You can read about this in more detail in our recent blog post.

Debugging

Debug Console messages show source location

Output messages in the Debug Console now optionally show the originating source location on the right hand side:

Output message show their source location

Clicking on this origin opens the source file in the editor.

Note: The following debuggers already support this feature:

We expect more debug extensions to adopt this feature soon.

Node Debugging

First steps towards WSL support

Thanks to a feature contributed by Bartosz Sosnowski (@bzoz), the Node.js debugger (for this milestone "legacy" protocol only), supports launching and debugging Node.js applications in the Windows Subsystem for Linux (WSL).

With this feature, you can add a useWSL flag to a debug configuration to make it run in the Linux subsystem on Windows. The flag configures the debugger not only to launch the Node.js runtime in WSL but it also maps paths correctly between WSL and Windows.

Here is the simplest debug configuration for debugging hello.js in WSL:

{
  "type": "node",
  "request": "launch",
  "name": "Launch in WSL",
  "useWSL": true,
  "program": "${workspaceFolder}/hello.js"
}

Viewing output from direct stdout/stderr writes

There are a number of Node.js logging libraries that write directly to the stdout stream, with process.stdout.write, rather than console.log. This is faster, but it isn't sent through Node's debug socket, so these messages were previously not shown in the Debug Console when debugging with the new 'inspector' protocol.

A PR #138 from Vakhurin Sergey (@igelbox) adds a new launch config option, "outputCapture": "std" which will tell the debug adapter to show stdout/stderr output in the Debug Console.

Tasks

We added multi folder support to tasks. If you have created a workspace with multiple folders, tasks from all workspace folders using task version "2.0.0" are collected and presented in the corresponding Run commands. Launch configuration can also reference tasks as preLaunch tasks from the same workspace folder.

Task Multi Root

Tasks auto detection for Gulp, Grunt, Jake and npm now also support multi-root workspaces. In addition, the task contribution API was enhanced to support contributing tasks for different workspace folders.

Please note that multi folder support still requires the Insiders build.

Languages

TypeScript 2.5.3

VS Code now includes TypeScript 2.5.3. This updates brings a few important fixes and improvements, with a focus on the extract method refactoring.

Import path quick suggestions in JavaScript and TypeScript

JavaScript and TypeScript have provided IntelliSense for import paths ever since VS Code 1.9. However, you may not have known about this feature because it required manually triggering IntelliSense while typing the import. With VS Code 1.17, we now automatically show module and path suggestions as soon as you start typing an import or require path:

Improved colorization in Dark+ and Light+ themes

VS Code's built-in Dark+ and Light+ themes now highlight regular expression components so that they can be more easily identified:

Dark+ colorization of a JavaScript regular expression

Colorization of format strings and string interpolation has also been improved for a few languages.

Python:

Dark+ colorization of Python format string

Ruby:

Dark+ colorization of ruby string interpolation

Extract method now triggers rename

The extract method and extract function refactoring for JavaScript and TypeScript will now automatically trigger a rename on the extracted method or function.

Auto detection of TypeScript watch build tasks

TypeScript now automatically creates watch tasks for tsconfig.json files in a project, along with the normal build tasks:

Build and watch tasks for a tsconfig.json file

JavaScript and TypeScript IntelliSense now supports Markdown

Suggestions and parameter hints for JavaScript and TypeScript can now render Markdown content.

Markdown in TypeScript suggestion documentation

Improvements to JSX language scoping

JavaScript expressions inside of JSX tags now are correctly marked as being of the JavaScript language. This fixes a number of bugs around basic language features such as bracket matching and code commenting.

Language support in Markdown code blocks

Fenced code blocks in Markdown files now set the language mode for their contents. This means that basic language features such as bracket matching and code commenting now use the settings for the fenced code block's language rather than the generic Markdown language settings:

Commenting and other basic editor features now use the language settings from the fenced code block's language

Detection of Markdown reference links

Reference links and reference link definitions are now detected as links in the editor:

Some text with a [link][link definition] in it

[link definition]: /path/to/link

Clicking on link definition will jump to [link definition]:. /path/to/link is now also detected as a link.

CSS language improvements

The built-in CSS/LESS/SCSS language server was updated and now supports the following features:

  • Validation and completion for the @supports rule.
  • Support for @import with queries.
  • Support for contain and various flex properties.

R language improvements

R has improved syntax highlighting based on the grammar published here.

Source Control

Improved multiple SCM support

Continuous iteration on the multiple source control provider support UX has led us to a master-detail implementation.

multiple scm providers

There is a new SOURCE CONTROL PROVIDERS section which gives you an overview when you have multiple active repositories. These can be contributed by several SCM providers; for example, you can have Git repositories side-by-side with Azure DevOps Server workspaces. As you select repositories in this view, they get highlighted underneath. You can use ctrl+click or shift+click to select multiple repositories. They will appear as split views underneath.

Increased Performance

We did quite a bit of performance work around the Source Control extension API and UI. Overall, the experience should be much smoother especially in repositories with a large number of objects.

Git stash commands

You might have missed this in the last release, but thanks to a PR from Krzysztof Cieślak (@Krzysztof-Cieslak), VS Code has Git stash commands in the Source Control view More Actions (...) dropdown.

git stash commands

New Documentation

Java language support

A new Java language topic describes how to install and use the Java Extension Pack for great Java code intelligence and debugging support in VS Code.

Tips and Tricks

We've added a Tips and Tricks topic to help you quickly become productive with VS Code. It includes the VS Code team's favorite features and keyboard shortcuts which they use on a daily basis.

Debugging Recipes

We've been working on recipes for various debugging scenarios and added a new topic outlining these guides and providing links to helpful blog posts. See Debugging Recipes for help on debugging frameworks such as React and Angular and runtimes like Electron and Docker.

Updated keyboard shortcut cheat sheets

We refreshed the keyboard shortcut PDFs and added the keybindings for useful commands such as Open User Settings (⌘, (Windows, Linux Ctrl+,)) and Open Keyboard Shortcuts (⌘K ⌘S (Windows, Linux Ctrl+K Ctrl+S)).

Extension Authoring

Multi root guide for extension authors

We are very close to shipping multi-root support for all users. All of the VS Code core features [SCM, Settings, Debug, Tasks, ...] and extensions [HTML, JS/TS, ESLint, Docker, ...] now support multi-root concepts.

We've created a guide for how to make your extension ready for multi-root workspaces. See the Adopting Multi Root Workspace APIs guide for more information. All the APIs discussed are considered stable and currently available. Note however that multi-root workspaces are only enabled in VS Code Insiders release.

The extension authors guide covers:

  • Basic APIs
  • Settings
  • Impact on extensions that have a language client/server model

In addition to the guide, there are new samples on our samples repository that exercise the new APIs. Look for samples with 'multi' in their folder name (for example, basic-multi-root-sample).

File Save & File Open dialogs

The extension API has two new functions that allow extensions to show dialogs for saving and opening files or folders. The snippet below will show an open dialog to select image files.

vscode.window
  .showOpenDialog({
    canSelectMany: true,
    filters: { Images: ['png', 'jpg'] }
  })
  .then(result => {
    if (result) {
      console.log(`${result.length} files have been selected`);
    }
  });

Styled completions and signature help

We have extended the API for CompletionItems and SignatureHelp such that documentation can be provided as MarkdownString. This allows for fancy rendering, embedded code snippets, and links to further documentation. Our own TypeScript and JavaScript extension is already using MarkdownString.

const item = new vscode.CompletionItem('Pretty');
item.documentation = new vscode.MarkdownString('*Hello*, `World`');

CompletionContext

CompletionItemProvider.provideCompletionItems now is provided with a new CompletionContext parameter. This context contains information about how the completion provider was triggered:

interface CompletionContext {
  /**
   * How the completion was triggered.
   */
  readonly triggerKind: CompletionTriggerKind;

  /**
   * Character that triggered the completion item provider.
   * `undefined` if provider was not triggered by a character.
   * The trigger character is already in the document when the completion provider is triggered.
   */
  readonly triggerCharacter?: string;
}

Touch Bar support

Extensions can now contribute commands to the touch bar on macOS. A new menu identifier touchBar was added for this purpose:

{
  "contributes": {
    "menus": {
      "touchBar": [
        {
          "command": "markdown.showPreview",
          "when": "editorLangId == markdown",
          "group": "navigation"
        }
      ]
    }
  }
}

The command context is always the currently active file making it possible to show and hide the command dynamically based on the when condition. It can either have a label or an icon. If the command provides an icon, the label will not be shown because the space is very limited in the touch bar.

Note: We currently require the commands icon to be of PNG file type. SVG is not supported.

Refer to the 'active' view column

The editor layout works with columns 1, 2, and 3 and when using the showTextDocument function, you can set a column. However, often you simply want to refer to the currently active column. To make that easy, we have added a new symbolic column: ViewColumn.Active. It will always show a document in the currently active column and saves you from figuring out what column that is.

Thanks to Eric Amodio (@eamodio) for this contribution.

MarkedString vs MarkdownString

Note that with this release, you cannot use command links in MarkedStrings anymore. If this affects your extension, we have likely already contacted you. In short, use the new MarkdownString and make sure to mark it as trusted. All the details and background can be found here.

New Source Control menu

You can now use the scm/sourceControl menu id to contribute commands to the inline source control provider rows in the new SOURCE CONTROL PROVIDERS section of the Source Control view. Only context menu commands are supported for now.

Tasks contribution API

The tasks API was enhanced to support contributing tasks for different workspace folders. The constructor to create tasks in an extension has an additional argument to specific whether the task is global, user local, or belongs to a workspace folder. The constructor signature looks like this:

export class Task {
  /**
   * Creates a new task.
   *
   * @param definition The task definition as defined in the taskDefinitions extension point.
   * @param target Specifies the task's target. It is either a global or a workspace task
   *  or a task for a specific workspace folder.
   * @param name The task's name. Is presented in the user interface.
   * @param source The task's source (e.g. 'gulp', 'npm', ...) presented in the user interface.
   * @param execution The process or shell execution.
   * @param problemMatchers the names of problem matchers to use, like '$tsc'
   *  or '$eslint'. Problem matchers can be contributed by an extension using
   *  the `problemMatchers` extension point.
   */
  constructor(
    taskDefinition: TaskDefinition,
    target: WorkspaceFolder | TaskScope.Global | TaskScope.Workspace,
    name: string,
    source: string,
    execution?: ProcessExecution | ShellExecution,
    problemMatchers?: string | string[]
  );
}

Debug API updates

Command vscode.startDebug is deprecated

With the introduction of a proper vscode.debug.startDebugging(...) API in the July release, it is no longer necessary to use the vscode.startDebug command to start a debug session. We've deprecating the vscode.startDebug command in August and still plan to drop it in October. If it is difficult for you to move off this feature, please speak up by commenting here.

Command vscode.workbench.customDebugRequest is deprecated

With the introduction of a proper DebugSession.customRequest(...) API in the July release, it is no longer necessary to use the vscode.workbench.customDebugRequest command to send a custom request to the debug adapter. We've deprecated the vscode.workbench.customDebugRequest command in August and still plan to drop it in October. If it is difficult for you to move off this feature, please speak up by commenting here.

Debug contributions in package.json

New Activation event onDebug

With the new debug API, extensions need a way to register their DebugConfigurationProvider early enough so that VS Code has them available when it needs them. Since DebugConfigurationProvider are typically registered in the activate function of an extension, we've introduced a new activation event onDebug which is fired just in time before any debugging activity starts (for example, configuring launch configurations or launching a debug session).

If your extension registers a DebugConfigurationProvider, make sure that your activationEvents contribution in the package.json has an onDebug entry.

Activation event onDebug:type is deprecated

With the introduction of the DebugConfigurationProvider API, it has become difficult to correctly support the activation event onDebug:type (where 'type' is a debug type). We recommend using the newly introduced activation event onDebug instead.

We are deprecating the onDebug:type activation event in the September milestone and plan to drop it in October. If it is difficult for you to move off this feature, please speak up by commenting here.

Using debuggers.startSessionCommand in package.json is deprecated

With the introduction of the resolveDebugConfiguration method on type DebugConfigurationProvider, it is no longer necessary to contribute a startSessionCommand on the debuggers contribution point. Therefore we are deprecating the startSessionCommand in this milestone and plan to drop it in October. If it is difficult for you to move off this feature, please speak up by commenting here.

Using command with debuggers.initialConfigurations in package.json is deprecated

With the introduction of the provideDebugConfigurations method on type DebugConfigurationProvider, it is no longer necessary to contribute a command for the debuggers.initialConfigurations contribution point. Therefore we are deprecating the ability to specify a command ID in this milestone and plan to drop it in October (but we will continue the support for contributing a JSON object literal). If it is difficult for you to move off this feature, please speak up by commenting here.

Debug Adapter Protocol

BreakpointEvent now supports a removed reason

A removed reason has been added to the value set of the reason attribute of BreakpointEvent. With this addition, a debug adapter can notify its client (frontend) that a breakpoint has been removed.

Please note: With this release, VS Code now fully supports the new, changed, and removed reasons of the breakpoint. Previously VS Code only supported a changed (or updated) breakpoint event. Please make sure that your breakpoint event uses the correct value for reason.

Locale can be passed to debug adapter

Optionally a client (frontend) of the debug adapter protocol can pass the current locale to the debug adapter so that it can choose the correct translation for any user visible information passed back to the client (for example, error messages). There is now an optional locale attribute on the initialize request.

Preview: Remote File System API

We are exploring support for "remote file systems". New APIs will allow extensions to contribute files and folders to the Explorer, allow to create, delete, move, and copy them, as well as to read and write files. The goal is that items from remote sources appear and behave just like files from your local disk.

The screen-capture below shows the files of an Azure function being edited like a file on disk.

File With Changes from Ftp

To familiarize yourself with this, see the proposed-apis and more importantly check out our ftp-sample. As we make progress and refinements on the API, we will make sure to keep this sample up to date.

Preview: Multi Root Workspaces

Note: Multi-root functionality is only available in the Insiders build until we are confident enough that we can make it available in Stable. To try it out, grab our Insiders build from https://code.visualstudio.com/insiders.

We continued working on support for opening multiple folders in a single VS Code window (instance) (issue #396). There was a preview of this feature in our last releases (see 1.14.0 release notes, 1.15.0 release notes and 1.16.0 release notes).

During this milestone, we focused on making the transition into a workspace work without a window reload and introduced more APIs for extensions to better support multi-root workspaces.

Enter a workspace without window reload

Previously we required a full window reload when creating or saving workspaces or when adding folders to a workspace. We no longer require this window reload making the multi-root experience a lot smoother.

Extension recommendations

We extended the support of extension recommendations to multi-root workspaces. Extension recommendations from all root folders are consolidated and shown. You can also configure recommendations for the multi-root workspace itself using the command Extensions: Configure Recommended Extensions (Workspace Folder). This will open the workspace configuration file and you can enter the recommendations under a extensions/recommendations section.

Extension Recommendations

New API: Workspace Folder Picker

With the advent of multi-root support in VS Code, we noticed that often an extension wants to ask the user for a specific WorkspaceFolder. The new proposed API method showWorkspaceFolderPick opens a picker and returns the result.

Workspace Folder Picker

New API: RelativePattern

To make it easier to filter file paths to a specific WorkspaceFolder, we added a new type RelativePattern and support it in the following places:

  • workspace.createFileSystemWatcher
  • workspace.findFiles(include, exclude)
  • DocumentFilter#pattern

The type is a class as follows:

/**
 * A relative pattern is a helper to construct glob patterns that are matched
 * relatively to a base path. The base path can either be an absolute file path
 * or a [workspace folder](#_WorkspaceFolder).
 */
class RelativePattern {
  /**
   * A base file path to which this pattern will be matched against relatively.
   */
  base: string;

  /**
   * A file glob pattern like `*.{ts,js}` that will be matched on file paths
   * relative to the base path.
   *
   * Example: Given a base of `/home/work/folder` and a file path of `/home/work/folder/index.js`,
   * the file glob pattern will match on `index.js`.
   */
  pattern: string;

  /**
   * Creates a new relative pattern object with a base path and pattern to match. This pattern
   * will be matched on file paths relative to the base path.
   *
   * @param base A base file path to which this pattern will be matched against relatively.
   * @param pattern A file glob pattern like `*.{ts,js}` that will be matched on file paths
   * relative to the base path.
   */
  constructor(base: WorkspaceFolder | string, pattern: string);
}

You can create a relative pattern via the following call:

// Construct a relative pattern for the first root folder
const relativePattern = new vscode.RelativePattern(
  vscode.workspace.workspaceFolders[0],
  '*.ts'
);

When a RelativePattern is used, file paths will be matched relative to the base path of the pattern. For example, given a base path of /home/work/folder and a file path of /home/work/folder/index.ts, the pattern within RelativePattern will match on index.ts.

Smarter workspace file format saving

When saving the workspace file back to disk upon changes, we will now prefer to use forward slashes for paths on Windows in case the file is already using slashes. This should make it easier to share workspace files between Windows and other platforms.

In addition, we now preserve any comments within the workspace file. Even though JSON does not allow for comments inside the file, we now use the same JSON parser that we use for VS Code settings which allows for comments and is also more error tolerant. For example, trailing commas will not render the workspace file as invalid anymore.

Workspace folder name

You can now assign a name property to each of the folders within the configuration file. The name will be picked up in the Explorer and can be used to distinguish multiple workspace folders that have the same basename.

Engineering

Issue management automation

We have extended the use of our Probot instance beyond our main repository and now use it for automatic issue assignment and closing of stale "needs more info" issues in our extension and other repositories.

Notable Changes

  • 27285: Cannot open a folder under my OneDrive folder
  • 25934: VS Code flickers when running on a high DPI external monitor
  • 35148: VS Code opens off-screen
  • 22696: Cmd-A doesn't select all text in the save dialog save-as field

Thank You

Last but certainly not least, a big Thank You! to the following folks that helped to make VS Code even better:

Contributions to vscode:

Contributions to vscode-eslint:

Contributions to language-server-protocol:

Contributions to vscode-node-debug:

Contributions to vscode-node-debug2:

Contributions to vscode-generator-code:

Contributions to vscode-github-issues-prs:

Contributions to vscode-recipes:

Contributions to localization:

This is the sixth month since we opened community localization in Transifex. We now have over 400 members in the Transifex VS Code project team. We appreciate your contributions, either by providing new translations, voting on translations, or suggesting process improvements.

Here is a snapshot of top contributors for this release. For details about the project including the contributor name list, visit the project site at https://aka.ms/vscodeloc.

  • French: Antoine Griffard.
  • Italian: Aldo Donetti, Piero Azi, Giuliano Latini.
  • German: LosSandreas, Carsten Kneip, Christian Gräfe, Dejan Dinic, Levin Rickert.
  • Spanish: Raul Rama, Carlos Mendible, Roberto Fonseca, Jorge Serrano Pérez, David Triana, José M. Aguilar, Andy Gonzalez.
  • Japanese: EbXpJ6bp, Yuichi Nukiyama, Yuki Ueda, tanaka_733, Kyohei MORIYAMA, Yosuke Sano.
  • Chinese (Simplified): Joel Yang, YingFeng, pluwen, Shawn Dai, Wang Weixuan, 林昊.
  • Chinese (Traditional): Winnie Lin, Duran Hsieh, Ke-Hsu Chen, Poy Chang.
  • Korean: HANSEULMARO KIM.
  • Portuguese (Brazil): Roberto Fonseca, Bruno Sonnino, Danilo Dantas, Alessandro Fragnani, Andy Gonzalez.
  • Hungarian: Tar Dániel, Attila Csaba Kiss.
  • Turkish: Adem Coşkuner.
  • Czech: Vojtěch Habarta, Frantisek Veris, Vít Staniček.
  • Dutch: Gerald Versluis, Maarten van Stam, Sander van de Velde, Armand Duijn, Splinter Suidman, Geert van der Cruijsen, Peter Hut.
  • Indonesian: Joseph Aditya P G, Herman Prawiro.
  • Polish: Wojciech Maj, Patryk Adamczyk.
  • Swedish: Joakim Olsson, Christian Svensson.
  • Bangla: Ferdous Ahmed, Reaz Patwary.
  • Vietnamese: Thanh Phu.