Vscode docs

GitHub - Microsoft/vscode-docs: Public documentation for Visual Studio Code
Repo URL: https://github.com/Microsoft/vscode-docs
Edited by:
Cover image: Cover image
Share this using: email, Google+, Twitter, Facebook.
Exports: EPUB | MOBI

1 July 2016 (version 1.4)

During July, we slowed down feature work in favor of reducing our bug backlog and removing engineering debt. However, we were still able to add some improvements.

Here are the highlights:

  • Workbench: Editor actions such as Open Preview and Switch to Changes View are back on the title bar. IME and Copy/Paste support in the Integrated Terminal.
  • Editor: Better snippet and suggestions control. New Insert Snippet command with dedicated UI.
  • Debugging: Restart Frame action to rerun a specific stack frame. ‘Variable paging’ feature moved into VS Code and available to all debug extensions.
  • Extension Authoring: New ‘move’ commands to better support VIM gestures. Custom link behavior with the DocumentLinkProvider API. Expanded Debug Protocol.

Downloads: Windows |
OS X | Linux 64-bit: .zip .deb .rpm | Linux 32-bit: .zip .deb .rpm

1.1 Editor

1.1.1 Snippets and Suggestions

By default, VS Code shows snippets and completion proposals in one widget. This is not always desirable so we added a new configuration setting called editor.snippetSuggestions. To remove snippets from the suggestions widget, set the value to "none". If you’d like to see snippets, you can specify the order relative to suggestions; at the top ("top"), at the bottom ("bottom“), or inline ordered alphabetically ("inline"). The default is "inline".

In addition, we added a new command to insert a snippet, Insert Snippet, which displays the available snippets in a drop down.

snippet insert

1.1.2 Tab Completion

The editor now supports kbstyle(Tab) completions. You can enable it with the editor.tabCompletion setting. After typing the prefix of a snippet, press kbstyle(Tab) to insert it.

tab completions

Note that quick suggestions and kbstyle(Tab) completion might interfere because the suggestions widget also reacts to kbstyle(Tab).

Either disable quick suggestions:

    "editor.quickSuggestions": false

or remove snippets from the suggest widget:

    "editor.snippetSuggestions": "none"

1.2 Workbench

1.2.1 Editor Actions

When we added Tabs (tabbed headings), we put editor actions (Switch to Changes View, Open Preview) into the context menu to gain some space. User feedback was clear that this made the actions much harder to discover and so we have added them back to the title header.

Menu Group Sorting

1.2.2 Drag and Drop

You can now drag and drop Tabs (tabbed headings) across windows. You can now also drop a folder into VS Code to open it.

1.2.3 Git commit message template

If you have a message template configured in your Git settings, then the Git view in VS Code will show that message in the commit message box by default. Thanks to William Raiford for contributing this feature.

1.2.4 Faster Quick Open

We made the first steps in improving the performance of Quick Open, particularly for large workspaces such as Chromium. On Mac (kbstyle(⌘+P)) and on Linux (kbstyle(Ctrl+P)), Quick Open on a Chromium workspace now takes less than half the time it took before. On Windows (kbstyle(Ctrl+P)), it originally took twice as long as on Mac and now it is just as fast. We are not finished, expect more performance gains in the next iteration.

1.2.5 Integrated Terminal

The integrated terminal had several changes related to polish and compatibility this release:

  • IME support: Input Method Editor (IME) support has been implemented, allowing input of CJK and Indic characters.

IME support in Visual Studio Code

  • Copy and paste support on Windows and Linux: Proper copy and paste support has arrived for Windows and Linux within the terminal. The default keybindings are kb(workbench.action.terminal.copySelection) and kb(workbench.action.terminal.paste) respectively. Note that these command keybindings are not assigned by default on Mac but you can easily add your own keybindings.
  • Context menu: A right-click context menu has been added with the options New Terminal, Copy and Paste.
  • Accessibility: It’s now possible to escape focus in the terminal by pressing kb(editor.action.toggleTabFocusMode) to enable kbstyle(Tab) focus mode, just like in the editor. When this mode is enabled, kbstyle(Tab) and kbstyle(Shift+Tab) will not be passed to the terminal but instead change the element that is being focused.

1.3 Languages

1.3.1 JSON completions

There has been some small improvements for the JSON completions:

  • In schema based JSON documents, we offer completions for empty arrays, objects and string if we know the type of a property but the schema doesn’t describe any defaults.
  • Completion support for the $schema property and values.

1.4 Debugging

1.4.1 Restart Frame

VS Code now supports restarting execution at a stack frame. This can be useful in situations where you have found a problem in your source code and you want to rerun a small portion of the code with modified input values. Stopping and then restarting the full debug session can be very time-consuming. The Restart Frame action allows you to re-enter the current function after you have changed variables with the Set Value action:

Restart Frame

Note that Restart Frame won’t unroll any state changes, so it may not always work as expected.

Restart Frame is only available if the underlying debug extension supports it and currently only VS Code’s built-in Node.js debugging does. Make sure to use a Node.js version >= 5.11 since earlier versions do not work in all situations.

1.4.2 Variable Paging

Previously VS Code expected that large data structures like arrays were broken into “chunks” in a debug extension and consequently only a few debug extensions supported this useful feature. With this release, we have moved this functionality into the VS Code debugger front-end so that all debug extensions can easily benefit from this in the future.

Variable Paging

See section “Debug Protocol Changes” below for details of how a debug extension can make use of this.

1.4.3 Double Click Debug Toolbar Centers

Double clicking on the Debug view toolbar drag icon will center the Debug toolbar. This makes it easy to restore the default state.

1.5 Extension Authoring

1.5.1 New settings to replace deprecated __characterPairSupport and __electricCharacterSupport.

The deprecated configuration settings can now both be replaced by the autoClosingPairs setting in the language-configuration.json file in your extension. See #9281 for detailed instructions.

1.5.2 Editor Commands

In order to allow the VIM extension to make good progress on their roadmap particularly on up-and-down motion and kbstyle(Tab) related commands, we added the following editor APIs:

  • Move cursor: Moves the cursor to different logical positions in the editor - See 9143.
commands.executeCommand('cursorMove', {to: 'up', by: 'wrappedLine', value: '2'})
  • Move active editor: Moves the active editor across groups or across Tabs within a group - See 8234.
commands.executeCommand('moveActiveEditor', {to: 'left', by: 'tab', value: '3'})

1.5.3 Sorting of groups

Last milestone, we added support to contribute menu items to different places in the editor. This milestone we refined sorting of groups. They are now sorted in lexicographical order with the following defaults/rules.

The context menu of the editor has these default:

  • navigation - The navigation group comes first in all cases.
  • 1_modification - This group comes next and contains commands that modify your code.
  • 9_cutcopypaste - The last default group with the basic editing commands.

Menu Group Sorting

You can add menu items to these groups or add new groups of menu items in between, below, or above. In this release, only the editor context menu allows this grouping control but it will soon be available for the editor title menu and the explorer context menu as well.

1.5.4 DocumentLinkProvider API

VS Code has a built in link detector that finds http, https, and file links to make them clickable in the editor. We have added new API that allows extension writers to add custom link detection logic. Implement a DocumentLinkProvider and use the registerDocumentLinkProvider function to register it with the editor.

1.5.5 Debug Extension Authoring: Additions to the Debug Protocol

The debug protocol has been extended in the following areas (and VS Code already provides the corresponding UI):

  • Restart Frame: If a debug adapter returns the capability supportsRestartFrame, VS Code shows a Restart Frame action in the context menu of the CALL STACK view and calls the new restartFrame request upon execution of the Restart Frame action. The restartFrame request must result in a StoppedEvent so that the UI can be updated for the new location.
  • Variable Paging: ‘Variables paging’ adds support for paging variables and their children. The debugger UI in VS Code 1.4 uses this to present variables with many children with a better scalable (paged) UI and fetches the children in a piecemeal way. A debug adapter can find out whether the client supports variable paging by checking the value of the supportsVariablePaging client capability passed as an argument to the initializeRequest.<br>
    Through the optional attributes indexedVariables and namedVariables, the debug adapter can return both the number of indexed properties (e.g. array slots) and named properties of a variable. These two properties can be returned in all places where a variablesReference property is returned, that is in the Variables and Scope data types and in the evaluateRequest response.<br>
    Additional optional attributes have been added to the variablesRequest to give the VS Code debugger UI better control over what children of a variable to fetch. An attribute filter is used to limit the fetched children to either indexed or named and the attributes start and count are used to further limit the children to a certain range.
  • Continued Event: A debug adapter can now optionally send a ContinueEvent to the client to indicate that the execution of the debuggee has continued.
  • Source request supports MIME type: A debug adapter can now set a mimeType attribute on the SourceRequest response which a client can use to find a suitable editor.
  • Variable Type client capability: A debug adapter can find out whether the client shows the variable’s type attribute in the UI by checking the value of
    the supportsVariableType client capability passed as an argument to the initializeRequest.

1.6 Notable Changes

  • 4842: Allow to disable drag and drop in the files explorer
  • 7839: Sometimes SVG icons do not show up on Windows 7
  • 8788: Weird tabs auto scrolling behaviour
  • 8704: Deleting folder containing dirty files closes dirty editors
  • 8617: Run selected text in active terminal is not running the selected text on Windows
  • 8219: Lines containing unicode characters in integrated terminal differ in height
  • 9010: Global search and replace: Support regular expression variables in replace

These are the closed bugs and these are the closed feature requests for the 1.4 update.

1.7 Thank You

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

2 June 2016 (version 1.3)

2.1 1.3.1 Recovery build

To fix several issues, we’re releasing a 1.3.1 recovery build. You can view the resolved issues here.

Downloads: Windows |
OS X | Linux 64-bit .zip .deb .rpm | Linux 32-bit .zip .deb .rpm

2.2 June Release Summary

We’re really excited about the June release of VS Code. We’ve made some big changes to Extension management (dedicated Extensions View) and added Tabs (tabbed editor panes). Other new features include global Search and Replace, improved Drag and Drop and optional indentation guides. All of this along with enhancements to existing features like the Integrated Terminal and delivering a set of important bug fixes.

Here are the highlights:

  • Tabs: Tabbed editor panes allow you to quickly navigate to your files and organize your workbench.
  • Extensions: New in-product Extensions View to quickly find, install and manage your extensions.
  • Workbench: Enhanced Drag and Drop, Preview Editors to conserve your editor panes, and multiple Integrated Terminals.
  • Editor: Global Search and Replace, Indent Guides, Problems panel to view errors and warnings.
  • Languages: Better, more complete Emmet support, Atom JavaScript grammar extension.
  • Debugging: Lots of improvements including support for attaching to running Node.js processes and changing variable values during a debug session.
  • Extension Authoring: A new contribution point for menu bars and context menus. New APIs to open non-text resources and add editor decorator attachments.

2.3 Tabs

With this release, VS Code shows open files as Tabs in the title area above the editor. You can move Tabs around via Drag and Drop to organize your files or right-click on a Tab to perform useful file specific actions.

Tabs

If you prefer not to use Tabs, you can disable them through the workbench.editor.showTabs setting.

When there is not enough available space to show all files, you will see Tabs overflowing to the left and right. You can always use the mouse to scroll left and right across all tabs. The little overflow icon (see image below) is enabled as soon as there are Tabs outside of the visible view. Clicking on the overflow icon shows a list of all Tabs opened in the group.

Tabs Overflow

You can use the new workbench.editor.openPositioning setting to control where new editors should open. By default they open to the right of the active Tab, but you can change this to open to the left, or to the beginning or end of all editors.

2.3.1 Open Editors View

The new OPEN EDITORS view in the Explorer is the replacement to the previous WORKING FILES view.

Open editors view

The OPEN EDITORS view is a visual representation of the editor (open file) stacks:

  • Each editor group with the editors that belong to it is shown.
  • Clicking on an editor will make it active and open it in the corresponding group.
  • Top level actions to close all or save all open editors.
  • Editor level actions to close or save an editor.
  • Context menu actions provide more refined actions.
  • It is possible to drag and drop editors between editor groups or from the Explorer

You can hide the OPEN EDITORS view by setting the number of visible items to 0, with "explorer.openEditors.visible": 0.

Note: Since the WORKING FILES view has been deleted, please refer to this issue to get an overview of the new or changed command identifiers.

2.3.2 More on Editor Stacks

As a preparation for enabling Tabs in the workbench, we revisited how you can interact with editors in VS Code. Many users coming from other tools were confused by some of the editor (open file) behavior in VS Code.

For example:

  • Closing a dirty editor (an editor with an unsaved file) did not prompt for saving.
  • Closing an editor, closed the entire group without revealing the previous editor.
  • The editor history showed a list of all editors ever opened and not a list of editors you opened in a group.
  • WORKING FILES view in the Explorer was a confusing concept.

With editor stacks, we’ve tried to address these issues:

  • You can open up to 3 editor groups side by side and each group contains a stack of editors.
  • Every time you open an editor, it is added to the top of the stack.
  • Closing an editor from a group reveals the editor that was previously opened in that group until the last editor closes and the group hides.
  • You get prompted to save for dirty editors.

Use kb(workbench.action.openPreviousRecentlyUsedEditorInGroup) to bring up a list of most recently used editors of a group for navigation. Use the View: Show All Editors command to show a list of all open editors across all groups.

Editor Stacks

Note that the behavior of editor stacks is independent from having Tabs enabled or not. You will benefit from these changes even if you don’t want to use Tabs.

Note: Due to the large conceptual impact of editor stacks, many command ids have been renamed and new commands introduced. Please refer to this issue that documents the changes. It also provides guidance if you liked the previous behavior and explains how to change key bindings back to the old behavior.

2.4 Extension Management

We have introduced a new Extensions View to improve finding, installing, and updating VS Code extensions.

To display the Extensions View, click the Extensions View icon or press kb(workbench.view.extensions):

extension view icon

By clicking on the ... More button, it is possible to show:

  • The list of currently installed extensions
  • The list of outdated extensions that can be updated
  • The list of recommended extensions based on your workspace
  • The list of globally popular extensions

Clearing the search box, shows the list of installed extensions.

Browsing through a list of extensions, it is possible to install, uninstall or update them. Clicking on an extension will display the detailed description in the editor area.

Extensions View

2.5 Workbench

2.5.1 Errors and Warning in the Problems panel

With the June release, we now offer a new Problems panel, docked at the bottom of VS Code, that shows errors, warnings and other information generated by different sources like language servers, linters and others. In previous releases, we showed the errors and warnings in the quick box at the top of the editor. We have received feedback from users that this made it difficult to review errors and warnings while editing files. The new panel makes it easy to navigate through your errors and warnings and fix them while the editor is still open.

Problems

A filter box is provided to search and filter among the problems shown. You can either filter by type or by text. For example, ‘errors’ will filter for all problems of type error. ‘character’ will filter for problems with messages containing the word ‘character’.

You can open the Problems panel by:

  • Using kb(workbench.actions.view.problems)
  • From the View | Problems menu
  • From the View > Show Problems command in the Command Palette

The key binding kb(workbench.actions.view.problems) that was used to show errors and warnings in the quick open/quick box will now open the Problems panel.

By default, the Problems panel scrolls and shows problems for your active file. If you don’t want this automatic reveal behavior, you can disable it through a setting problems.autoReveal. Set problems.autoReveal to false to prevent your Problems view from changing as you switch between active files.

Note: This view is just a representation of markers generated by the language servers or linters or build tasks or any external builders configured in or outside your workspace. You have to configure or customize them appropriately in order to see the expected problems.

2.5.2 More powerful Drag and Drop

With all the work on Tabs, we also looked at improving the Drag & Drop support in the editor. We always allowed you to drop files from outside VS Code into the editor to open the files and now there is a lot more that you can do:

2.5.2.1 Drop to Split

Drag some files to the left or right area of an editor to open it to the side of that editor. You can either drag from the Explorer or a Tab if Tabs are enabled.

Drop to split

2.5.2.2 Drop Feedback

Whenever you are dragging files or a Tab over the editor area, you now get drop feedback to indicate the target position of the drop.

2.5.2.3 Drag from Explorer and Opened Editors view

You can now drag a file or editor from the Explorer and the OPEN EDITORS view to the editor space to open it at a specific location.

2.5.3 Preview Editors

Closely related to editor stacks and Tabs are preview editors. If you are browsing many files, you might not want to see a Tab opened for each file you open. Preview editors help reduce the number of opened editors (and Tabs) by reusing the current editor. A file will open in preview mode if you open it by single clicking in the Explorer. As long as the editor stays in preview mode, other files will open in the same location as the preview editor.

Certain actions cause a preview editor to become a normal editor:

  • When you modify the contents of a file, the editor will be kept open.
  • The same is true for when you double-click on a file in the Explorer or inside a Tab or move a file to a specific editor group.

Preview editors are indicated using an italic font style.

Preview Editor

We introduced new settings to control the behavior of preview editors:

  • workbench.editor.enablePreview to globally enable or disable preview editors.
  • workbench.editor.enablePreviewFromQuickOpen to enable or disable preview editors when opened from quick box/quick open.

2.5.4 Integrated Terminal

The integrated terminal that was introduced in VS Code 1.2.0 has seen many improvements this release, the primary one being the ability to launch and use multiple terminals at the same time. Terminal instances can be added by hitting the plus icon on the top-right of the TERMINAL panel or by triggering the kb(workbench.action.terminal.new) command. This creates another entry in the dropdown list that can be used to switch between them.

Multiple terminal instances

Several new commands were added to aid with management of the TERMINAL panel and its terminal instances.

They are:

  • workbench.action.terminal.focus: Focus the terminal. This is like toggle but focuses the terminal instead of hides it if its visible.
  • workbench.action.terminal.focusNext: Focuses the next terminal instance.
  • workbench.action.terminal.focusPrevious: Focuses the previous terminal instance.
  • workbench.action.terminal.kill: Remove the current terminal instance.

The ability to run selected text in the current terminal has been added through the workbench.action.terminal.runSelectedText command.

To use this command, select text in an editor and run the command via the Command Palette:

Run selected text

Run selected text result

The following improvements were also added:

  • Copy and paste on Linux and Windows is now available using kbstyle(Ctrl+Insert) and kbstyle(Shift+Insert) respectively. This is temporarily non-configurable until we can route custom copy/paste keybindings to the xterm.js library.
  • CJK characters should now use the correct width. Credit for this goes to @jerch in this PR.
  • Performance of the terminal has improved significantly and should no longer perform poorly when running commands that produce large output.
  • kbstyle(Ctrl+Left) and kbstyle(Ctrl+Right) now tells the underlying shell to jump over words in the input.
  • Terminal cursor blinking is now enabled by default. It shares the configuration value with the editor’s editor.cursorBlinking setting.
  • A hollow cursor is shown when the terminal is not focused.
  • Terminal font size and line height can be customized via settings, thanks to a PR from @kisstkondoros.
  • Selection has been improved to now select the full line, contain no margin and also invert the text colors.
    Terminal selection has been improved
  • Arguments can be passed to the terminal shell on Linux and OS X using the terminal.integrated.shellArgs.* settings.

2.5.5 Command Palette: File: Open Recent in new Window

The command File: Open Recent from the Command Palette makes it very easy to quickly switch between previously opened folders or files. Usually the selected file or folder would open in the running instance. In this release, we added support to open into a new window if you select an entry while having the kbstyle(Ctrl) (kbstyle('Cmd') on Mac) key pressed.

2.5.6 Restore Full screen

A new setting window.restoreFullscreen has been added to open VS Code in full screen if it was previously closed in full screen mode.

2.6 Editor

2.6.1 Global Search and Replace

Global Search and Replace was one of the most requested features from our users. With this release, we enhanced our Search view to include Replace functionality so that you can replace text across multiple files. You can replace in all files or pick file by file or result by result. You can also exclude results or files and then perform replace on the rest. The Search view gives you a nice preview and clicking on a pending change will bring up the Diff editor view showing the file before and after replace.

Search and Replace

Replace functionality can be accessed:

  • In the Search View by expanding the Search textbox
  • Using kb(workbench.action.replaceInFiles), from the Edit | Replace in Files menu
  • Using Replace in Files command in the Command Palette

Note: Since Search has a limitation of showing a maximum of 2048 results, Replace currently has the same limitation.

2.6.2 Indent Guides

VS Code can now show indent guides, enabled with the editor.renderIndentGuides setting.

Editor Indent Guides

2.6.3 Suggestions for command identifiers

When authoring the keybindings.json file, you now get completions for the available commands.

Command Completions

2.6.4 Editor Font Zooming with mouse wheel

Thanks to @kisstkondoros, with PR #6990, after setting editor.mouseWheelZoom: true, it is possible to change the font size of the editors by pressing kbstyle(Ctrl) (kbstyle('Cmd') on Mac) and scrolling with the mouse wheel:

Mouse Wheel Zoom

2.6.5 Multiline Find

We have added support for multiline Find and Replace:

Editor Indent Guides

2.6.6 Emmet

Thanks to some great support from Denis Malinochkin (@mrmlnc) through Pull Requests and testing help, we are now covering many more Emmet features (Wrap with Abbreviation, Remove Tag, Update Tag, Balance, Toggle Comment, …).

2.7 Languages

2.7.1 Extract CSS/LESS/SCSS and JSON into extensions

The CSS, LESS, and SCSS language support has been refactored to be regular VS Code extensions. As all these languages are based on the same code base, they share the same language server. The language server runs in a separate node process, using the language server protocol to communicate with VS Code.

2.7.2 Extract Markdown into an extension

The Markdown language support has been refactored to be a regular VS Code extension. It uses the Markdown TextMate grammar for syntax highlighting source and renders the Markdown as HTML using the markdown-it library which implements the CommonMark Spec.

2.7.3 Atom JavaScript grammar

As an alternative to the built-in JavaScript grammar, you can now install the Atom JavaScript grammar. It differs from the built-in grammar in that it creates tokens for variable and function references which, if supported by the theme, can be colorized differently.

2.8 Debugging

2.8.1 Moveable Debug Toolbar

Initiated by this user request, it is now possible to drag the debug toolbar horizontally:

Drag debug toolbar

2.8.2 Changing Variable Value

We now support changing the value of simple variables if a debug extension supports this.

Node Debug is the first extension to do so:

Drag debug toolbar

A simple variable is a leaf in the variables tree, e.g. a variable, an object property, or an array element.

2.8.3 Show Variable Type on Hover

If a debug extension supports variable types, we now show the type when hovering over the variable name.

2.8.4 Step Back

If a debug extension supports step back we now expose a step back action and button:

Step back

2.8.5 OS specific launch configurations

Initiated by a user request, it is now possible to specify OS specific configurations inside a launch.json:

{
   "type": "node",
   "request": "launch",
   "runtimeExecutable": "mynode",
   "windows": {
     "runtimeExecutable": "mynode.exe"
   }
}

2.9 Node.js Debugging

2.9.1 Attach to Process

Node.js debugging now supports attaching to a Node.js process that has not been started in debug mode. This can be useful if you need to debug a production server that cannot always run in debug mode for performance reasons.

In order to attach to a Node.js process, you specify its process id via a processId attribute in an attach launch configuration.

Since it is not very practical to always having to edit the launch configuration before starting a debug session, we’ve introduced a new type of variable that can bind to an interactive UI, e.g. to a process picker:

Process Picker

Here is a launch configuration that uses the ${command.PickProcess} variable to let the user select a Node.js process before starting the debug session:

{
   "name": "Attach to Process",
   "type": "node",
   "request": "attach",
   "processId": "${command.PickProcess}"
}

2.10 Extension Authoring

We now allow extension writers to contribute to the Explorer context menu (explorer/context), the editor context menus (editor/context), and the editor title menu (editor/title).

It works in two steps:

  1. Assign a title and an icon to a command using the enhanced commands contribution point.
  2. Create menu items using the new menus contribution point.

A menu item is defined for a menu location like editor/context and must at least specify the command to run. To avoid overly cluttered menus, a menu item should also specify a condition under which it shows. Last, an alternative command and a group into which the item is sorted can be defined. Groups are visually separated and there is a special group called navigation which is the most prominent.

"commands": [{
    "command": "markdown.showPreview",
    "title": "Open Preview",
    "icon": {
        "light": "./media/Preview.svg",
        "dark": "./media/Preview_inverse.svg"
    }
}],
"menus": {
    "explorer/context": [
        {
            "when": "resourceLangId == markdown",
            "command": "markdown.showPreview",
            "group": "navigation"
        }
    ]
}

Menu contribution

The snippet above adds an entry into the navigation group of the Explorer context menu when the resource is of the Markdown language. Note that the URI of the current resource is passed to the command when being executed from a menu item.

2.10.2 Add decorations before and after text

New capabilities have been added to the decoration APIs. You can now add ‘attachments’ before and after a decoration. Attachments can be icons as well as text content that sticks to the decorated text.

An example are the CSS color decorators attached to color values in the text:

Decorator attachment

Decoration attachments can be defined on decoration types (see the before and after properties on ThemableDecorationInstanceRenderOptions) and fine-tuned on individual decorations (see the before and after properties on ThemableDecorationRenderOptions). You can review these properties in the vscode namespace API reference.

2.10.3 API tweaks

  • The Uri-class now allows you derive a Uri from an existing one: someUri.with({scheme: 'newScheme', path: 'newPath'})
  • The previewHtml command now allows you to provide a title.
  • When previewing html, we expose the style of the current theme via class names of the body element. Those are vscode-light, vscode-dark, and vscode-high-contrast.
  • Last, there is a new command vscode.open to open non-textual resources like images.

2.10.4 Debug Extension Authoring: Command Variables

VS Code has supported variable substitution in launch.json configurations for some time. This release introduces a new type of variable that is bound to a VS Code command. When a debug session is started, all command variables that occur in the underlying launch configuration are first collected and then executed. Multiple occurrences of a variable do not result in multiple execution. Before the launch configuration is passed to the debug adapter, all variables are substituted with the command results.

A command is implemented and registered in an extension and its return value is used as the variable’s value. The implementation of a command can range from a simple expression with no UI, to some sophisticated functionality based on the UI features available in the extension API.

An example for this functionality can be found in node-debug. Here a variable ${command.PickProcess} is bound to a process picker command. A new ‘Attach to Process’ launch configuration uses the variable to let the user pick a Node.js process when running the launch configuration.

Introducing a new command variable is simple:

  • Implement and register the command in your extension (not in the debug adapter).
  • Add a variables section to your debuggers contribution point.
  • Add one name/command-binding per variable.

For example:

"debuggers": { ... "variables": { "RemoteHost": "askUserForRemoteHostCommand" }, ... }

  • The variable can now be used in any string typed value of a launch configuration as ${command.RemoteHost}.
  • To make the RemoteHost variable discoverable for the user consider adding it to the configurationAttributes or initialConfigurations sections of the debuggers contribution point.

2.10.5 Debug Extension Authoring: Additions to the Debug Protocol

The debug protocol has been extended in three areas (and VS Code already provides the corresponding UI):

  • Editing variables: If a debug adapter returns the capability supportsSetVariable, VS Code supports setting the value of unstructured (leaf) variables in the Variables view by calling the setVariable request.
  • Stepping backward: If a debug adapter returns the capability supportsStepBack, VS Code enables the UI for stepping back and will call the stepBack request.
  • Show variable type on hover: If a debug adapter returns the optional type attribute for the variable type, VS Code will show the value of this attribute when hovering over the variable’s name.

2.10.6 Creating Errors/Warnings from an Extension (Diagnostics)

With the introduction of the new Problems panel, we started to work on support for project wide builders and linters. As a first step, we eliminated the automatic clearing of problems when an document is closed. Otherwise opening and closing a document would change the problem set generated by a project wide builder. Due to this change, extensions like linters generating diagnostics are responsible for clearing them when a document is closed. All extension providers generating diagnostics need to adopt to this change.

In a linter that uses the vscode-language-server node module, this can be achieved as follows:

documents.onDidClose((event) => {
  connection.sendDiagnostics({ uri: event.document.uri, diagnostics: [] });
});

2.11 Monaco Editor

The Monaco Editor is now on npm! It is the VS Code source code editor extracted and packaged as a library that can be integrated in any web application to work in any modern browser. We have created a playground showcasing some of the APIs. You can get it via npm install monaco-editor.

All further Monaco Editor specific release notes will be available at its distribution repository.

Monaco Editor Playground

2.11.1 CSS/LESS/SCSS and JSON language services are now available

Additionally, the CSS/LESS/SASS parser and language intelligence source code has been extracted to a separate node module vscode-css-languageservice which is used by both the Monaco editor as well as VS Code, bringing the same CSS editing experience to the web browser.

Same for JSON, where the language service, including the JSON schema validator, were extracted to vscode-json-languageservice which again is shared with the Monaco editor.

2.12 Notable Bug Fixes

The SASS mode language id has been renamed from ‘sass’ to ‘scss’. If you have customized any linter settings for Sass, just rename the configuration keys from ‘sass.’ to ‘scss.’.

  • 6316: Update should reopen all last opened folders
  • 1210: Open file dialog should start in the directory for the current active file
  • 7391: editor becomes unresponsive all the time since last update
  • This fix improves the memory footprint of all colorizers through the use of immutable linked lists for representing colorizer states in-between lines in vscode-textmate.
  • 8173: Noticeable delay opening a Markdown file (source)
  • The implementation of a 10x faster hand-written plist parser for TextMate grammars improves the start-up time of all colorizers. We are looking into extracting this implementation to its own node module.

In addition, the following bugs were fixed with the Integrated Terminal:

  • #7911: Terminal lines appears to have margin
  • #7684: Clicking into editor does not properly take focus from Terminal view
  • #7458: Runaway terminalProcess processes
  • #6738, #7442, #7444: Several issues related to resizing the terminal
  • #6743: Mouse wheel scrolling in integrated terminal only works on filled areas
  • #7357: Invoking the terminal sometimes yields an error “Cannot set property ‘innerHTML’ of undefined”
  • #6457: vim overrides the terminal color scheme

These are the closed bugs and these are the closed feature requests for the 1.3 update.

2.13 Downloads

Downloads: Windows |
OS X | Linux 64-bit .zip .deb .rpm | Linux 32-bit .zip .deb .rpm

2.14 Thank You

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

3 May 2016 (version 1.2)

3.1 1.2.1 Recovery build

To fix several performance and Git integration issues, we’re releasing a 1.2.1 recovery build. You can view the resolved issues here.

Downloads: Windows |
OS X | Linux 64-bit .zip .deb .rpm | Linux 32-bit .zip .deb .rpm

3.2 1.2.0 May release

The May release of VS Code has some great new features, enhancements to existing features, and a set of important bug fixes.

Here are the highlights:

  • Editor: Ability to trim automatically inserted whitespace, a new key binding to select all find matches, and the Peek view is now resizable.
  • Linting: ESLint now supports the ability to fix all problems and TSLint supports quick fixes and file exclusion.
  • Languages: Code completion (IntelliSense), Go To and Peek Definition, and Find All Occurrences support for CSS variables in CSS, SCSS, and LESS files.
  • Workbench: A new integrated Terminal allows you to stay in VS Code while using your platform’s shell, we’ve added the ability to remove key bindings, and we’ve made progress on Tab support, which you can preview using the Insiders Release.
  • Debugging: You can now control how the Debug Console is revealed and we’ve improved stepping performance for Node.js applications with large numbers of local variables.
  • Extensions: You can now list, install, and uninstall extensions from the command line. For extension authors, we’ve expanded our debug, TextMate grammar, and command APIs and we’ve improved the Language Server Protocol.

Please continue reading for more information on what’s new in May.

3.3 Editor

3.3.1 Trim auto whitespace

The editor automatically inserts whitespace when you add a new line, based on indenting rules and the previous line’s content. Over time, this can result in unnecessary whitespace being persisted in the file. Thanks to PR #5423, the new editor.trimAutoWhitespace setting causes the editor to track the automatic whitespace it inserted and remove it if it no longer is needed, for example by typing somewhere else. Please note, this new setting is on by default.

Trim Auto Whitespace

3.3.2 Select all find matches

You can now immediately select all find results by pressing kb(editor.action.selectAllMatches). This is much quicker than doing a find and replace and leverages VS Code’s multi-cursor support. Thanks for PR #5715!

Find All Matches

3.3.3 Configure Word Based Suggestion

When a language service isn’t able to compute semantic completion (suggestions), VS Code defaults to word based completions. This is why for some languages you see an IntelliSense list with every word in the file. Some folks would prefer to not see this list at all so you can now disable word based completions with the editor.wordBasedSuggestions setting.

3.3.4 Resizable Peek View

The Peek view editor that shows for reference search and for previewing declarations can now be resized!

Peek

3.4 Workbench

3.4.1 Tabs

Note: Support for Tabs is not in the 1.2.0 (May 2016) Stable release. You can preview the experiences below by using the Insiders Release of VS Code.

Tab support is the number one User Voice request. While the full implementation will take multiple iterations to fully deliver, we wanted to share progress made during the May iteration.

During this milestone, we focused on managing stacks of open editors. In the picture below, you can see that the left pane has two editors open, the center pane has four, and the right pane has two more. Files listed in italics are preview files, they allow you to single click and browse files without cluttering the list of open editors and eventually tabs.

Tabs

When you close an editor the last opened editor in the stack is restored, instead of closing the pane as it does today. In addition, we held a number of UX studies that have resulted in further improvements to the design, including:

  • Redesign of the overflow icon
  • Ability to specify if files from Quick Open are pinned or previewed
  • Added a command to turn a previewed file into a pinned file

This work has been checked into master and you can preview it using the Insiders Release.

3.4.2 Integrated terminal

Number two on User Voice is the request for an integrated terminal, issue #143. It can be convenient to have a terminal embedded directly in the tool, initially scoped to the workspace you are working in. You don’t have to switch windows or alter the state of an existing terminal for a quick task.

With the May release, we are rolling out the initial version of an integrated terminal. You can open the terminal using kb(workbench.action.terminal.toggleTerminal), from the View | Integrated Terminal menu, or from the View > Toggle Integrated Terminal command in the Command Palette.

The shell that is used defaults to $SHELL on Linux and OS X, and %COMSPEC% on Windows. These can be overridden manually by setting terminal.integrated.shell.* in settings. It should act just like the terminal you’re familiar with.

Terminal

Please note, this is an early version of what we want to deliver. Currently VS Code only supports a single terminal and there still are missing features like copying and pasting with the keyboard. Windows 10 users may experience problems getting cmd.exe to work. If so, please try enabling the legacy terminal as described in #143. The full list of current bugs and feature requests can be found here.

Note: The Toggle Integrated Terminal key binding kb(workbench.action.terminal.toggleTerminal) had previously been bound to the Cycle Between Open Editors command. You can customize the key bindings and change the behavior back if desired.

3.4.3 Removing a specific key binding rule

It is now possible to write a key binding rule that targets the removal of a specific default key binding. With the keybindings.json, it was always possible to redefine all the key bindings of VS Code, but it can be very difficult to make a small tweak, especially around overloaded keys, such as kbstyle(Tab) or kbstyle(Escape). From now on, simply add a - to the command and the rule will be a removal rule.

Here is an example:

// In Default Keyboard Shortcuts
...
{ "key": "tab", "command": "tab", "when": ... },
{ "key": "tab", "command": "jumpToNextSnippetPlaceholder", "when": ... },
{ "key": "tab", "command": "acceptSelectedSuggestion", "when": ... },
...

// To remove the second rule, for example, add in keybindings.json:
{ "key": "tab", "command": "-jumpToNextSnippetPlaceholder" }

3.5 Languages

3.5.1 CSS Variables

Variable support in CSS is a new standards proposal currently in draft form. VS Code now supports rich code completion (IntelliSense) for CSS variables as well as Go To Definition, Peek Definition, and Find All Occurrences for variables in the same file.

For example, here we Peek (kb(editor.action.previewDeclaration)) at the definition of --bg-color:

css peek definition

3.6 Linters

3.6.1 ESLint

The ESLint extension now supports a “fix all problems” command. You can bind the eslint.fixAllProblems command to a keyboard shortcut, such as:

[
    { "key": "ctrl+shift+alt+f",   "command": "eslint.fixAllProblems",
                                     "when": "editorTextFocus" }
]

3.6.2 TSLint

The TSLint extension now supports excluding files from linting (PR #47) as well as quick fixes for a set of TSLint warnings (PR #40). Thanks for the pull requests!

3.7 Debugging

3.7.1 Control opening the Debug Console

To provide greater control over how the internal Debug Console is revealed VS Code, we are introducing the internalConsoleOptions setting in launch.json (see #6159). This is especially useful if you are using an external terminal while debugging and you want to keep VS Code focused on your code. The possible values are:

  • neverOpen - VS Code will never open the debug console
  • openOnFirstSessionStart - VS Code will open the debug console on the first debug session
  • openOnSessionStart - VS Code will open the debug console on every debug session

3.7.2 Node.js Improved Stepping Performance

We want VS Code to remain lightweight and fast so to improve the stepping experience for programs with a large number of local variables per scope, we’ve made the following adjustments for Node.js debugging:

  • If a scope has more than 100 local variables, VS Code no longer automatically auto expands that scope
  • After you expand the scope manually, only the first 100 local variables are shown

The scope header will reflect that only the first 100 local variables are being displayed:

100 Local Variables

To track a variable that is not within the first 100 you must add it as a Watch expression or evaluate it in the Debug Console.

3.8 Extension Authoring

3.8.1 Debug extension API

We have exposed a vscode.startDebug command as an extension API for the VS Code debugger component. With this, a debug session can be started programmatically either by passing the name of a launch configuration file or a complete launch configuration object:

    let launchConfig = {
        type: "node",
        request: "launch",
        program: "${workspaceRoot}/test.js",
        cwd: "${workspaceRoot}"
    };

    vscode.commands.executeCommand('vscode.startDebug', launchConfig).then(() => {
        vscode.window.showInformationMessage('Debug session started successfully');
    }, err => {
        vscode.window.showInformationMessage('Error: ' + err.message);
    });

More details can be found here.

3.8.2 TextMate grammar injections

Extensions can now contribute TextMate grammars that inject new rules into the existing grammars used for syntax highlighting. This makes it possible to add colorization inside string literals or comments, such as highlighting of URLs or TODO markers across multiple languages.

"grammars": [
  {
    "scopeName": "source.todo",
    "path": "./syntaxes/todo.tmLanguage",
    "injectTo": [  "source.js", "source.ts" ]
  }
]

3.8.3 Comparing files

We have added a new API command that allows you to use the diff-editor on two arbitrary resources like so: commands.executeCommand('vscode.diff', uri1, uri2)

3.8.4 Updated extension samples

There is a new rich extension sample that walks you through virtual documents, eventing, and using language features as commands. Also, the preview html sample was updated:

3.8.5 Debug Adapter: Support a ‘One’ or ‘All’ mode of operation for controlling threads

In a previous revision of the VS Code Debug Protocol, we had introduced a allThreadsStopped attribute on the StoppedEvent. With this attribute, a debug adapter can report back to the frontend whether only a single thread or all threads have stopped. Thanks to developer feedback, we learned that a similar attribute is necessary for the ContinueRequest too.

In the version 1.9.0 of the VS Code Debug Protocol, a boolean attribute allThreadsContinued has been added to the response from the ContinueRequest. Using this attribute, a debug adapter can report back to the UI whether only a single thread or all threads are continuing. More details can be found here.

3.8.6 Language Server Protocol

The Language Service Protocol now offers support for telemetry notifications. Message tracing support has been implemented in the node client library to help tracking down problems in the server. It can be enabled via a settings ${clientName}.trace.server where client name is the name passed when creating the LanguageClient instance. For example eslint.trace.server for the ESLint linter service.

3.8.7 Command Line Extension Management

To make it easier to automate and configure VS Code, it is now possible to list, install, and uninstall extensions from the command line.

Example:

code --list-extensions
code --install-extension ms-vscode.cpptools
code --uninstall-extension ms-vscode.csharp

3.9 The Monaco Editor

At the heart of VS Code is the “Monaco” code editor. You can find the “Monaco” editor across many Microsoft properties such as OneDrive, VSTS, Azure, the TypeScript playground, and even in the F12 tools in IE and Edge.

Our goal is to enable anyone to consume the “Monaco” editor and host it in any browser. The challenge we have today is that the editor is embedded in the vscode repository and the language service extensions have dependencies on client (non browser) technologies.

The first step towards releasing the editor is an exploration where the TypeScript language service has been extracted from VS Code’s sources and can run on top of the standalone editor API.

In the upcoming weeks we will continue to refine the API and automate the packaging with the goal of making the “Monaco” editor public with the June release of VS Code.

3.10 Notable Bug Fixes

  • 959: Fonts become fuzzy after zooming and scrolling
  • 1000: Slow response when system is offline
  • 2717: “Define Keybindings” is invalidating keybindings.json
  • 4541: Problem typing in Korean
  • 5645: Slow call stack response for TS repository
  • 5780: Come up with better external terminal defaults on Linux
  • 6029: debug doesn’t work on node v6
  • 6151: The border of scroll bar is ugly, and unclear under high dpi
  • 6432: Unity desktop entry not installed immediately after installation
  • 6525: Linux CLI fails to open files with spaces in filename
  • 6530: source maps don’t work if drive letter case does not match
  • 6593: Two desktop entries appear on Ubuntu sometimes
  • 6609: Change keybinding for ‘fold all’ / ‘unfold all’
  • 6878, 6916: Freeze/Crash when dealing with minified js files

These are the closed bugs and these are the closed feature requests for the 1.2.0 update.

3.11 Downloads

Downloads: Windows |
OS X | Linux 64-bit .zip .deb .rpm | Linux 32-bit .zip .deb .rpm

3.12 Thank You

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

4 June 2015 (0.3.0)

Thank you for using Visual Studio Code and keep the feedback coming! Based on your feedback, we added some frequently requested enhancements and provided over 300 minor improvements and bug fixes. This release is available now and is just the start - from this point on, you should expect to see an update roughly every month.

See how to update to get the bits. Read on for details about the many changes in this release.

4.1 Key Bindings

Based on user feedback (thanks!) we’ve decided to make some key binding changes. If you do not like our changes, you can always change key bindings as described in the keybindings documentation.

  • The native File Open dialog has been restored to kb(workbench.action.files.openFile). We received strong feedback that using this key for the Code File Open dialog is confusing.
  • The Code File Open dialog is now accessible via kb(workbench.action.quickOpen). We needed to find a new key for the Code File Open dialog. Since many editors are now using kb(workbench.action.quickOpen) for their enriched File Open dialog, we decided to go with this trend.
  • Go To Definition is now kb(editor.action.goToDeclaration) (formerly kbstyle(Ctrl+F12) on Windows). Visual Studio users suggested to align Go To Definition with Visual Studio. This wasn’t an option in the past when the VS Code editor was running inside the browser, since F12 was opening the developer tools.
  • kbstyle(Cmd+Up) and kbstyle(Cmd+Down) now work as expected on the Mac by jumping to the beginning and end of the file.
  • Format code is now kb(editor.action.format)

4.2 Command line args

You can now create a new file from the command line. For a file that doesn’t exist yet, append the file path to create it. VS Code will open it as a dirty (modified but not yet saved) file in the editor.

code mynewfile.js

You can open multiple folders and/or files from the command line. Just append multiple folder and/or file paths to open multiple sessions of VS Code.

code c:\myfolder1 c:\myfolder2 c:\myapp\program.cs

You can also open a new session instead of restoring the previous session. Use a new switch, -n or --new-window, if you want to start VS Code without restoring the previous session.

code -n

4.3 Editing

4.3.1 Multi-cursor

Here’s multi-cursor improvements that we’ve made.

  • kb(editor.action.addSelectionToNextFindMatch) selects the word at the cursor, or the next occurrence of the current selection.
  • kb(editor.action.moveSelectionToNextFindMatch) moves the last added cursor to next occurrence of the current selection.
  • The two actions pick up the matchCase and matchWholeWord settings of the find widget.
  • kb(cursorUndo) undoes the last cursor action, so if you added one cursor too many or made a mistake, press kb(cursorUndo) to return to the previous cursor state.
  • Insert cursor above (kb(editor.action.insertCursorAbove)) and insert cursor below (kb(editor.action.insertCursorBelow)) now reveals the last added cursor, making it easier to work with multi-cursors spanning more than one screen height (i.e., working with 300 lines while only 80 fit in the screen).

4.3.2 Comment action

We added these changes for comment actions.

  • kb(editor.action.addCommentLine) now forces adding line comments.
  • kb(editor.action.removeCommentLine) now forces uncommenting lines. (If multiple lines are selected, and not all of them have a line comment, the line comments will still be removed).
  • kb(editor.action.commentLine) toggles line comment as before, but now inserts the line comment tokens aligned with the indentation of the selected code. It also will leave empty or whitespace-only lines untouched. kb(editor.action.commentLine) is also more forgiving with regards to selection state when toggling comments in languages which only support block comments, such as CSS or HTML.
  • Toggle block comment (kb(editor.action.blockComment)) is also more forgiving related to selection state when toggling block comments.

Block comments

4.3.3 Indentation

Pressing kbstyle(Tab) on an empty line will indent as much as needed to place the cursor at the correct starting position (i.e., not just insert a single indentation).

4.3.4 Shrink/expand selection

Quickly shrink or expand the current selection (applies to all languages). Trigger it with kb(editor.action.smartSelect.shrink) and kb(editor.action.smartSelect.grow)

Here’s an example of expanding the selection with kb(editor.action.smartSelect.grow):

Expand selection

4.3.5 Wrapping control

To improve readability, you can now control how long lines are wrapped and indented with a new setting, editor.wrappingIndent, in settings.json. The following values are available for editor.wrappingIndent:

  • none: When a line wraps, subsequent lines start at column 1.

    WrappingIndent set to none

  • same: (This is the default.) When a line wraps, subsequent lines start at the same column used by the original line.

    WrappingIndent set to none

  • indent: When a line wraps, subsequent lines are indented once relative to the original line.

    WrappingIndent set to indent

4.4 Debugging

In launch configurations, you can now use the runtimeArgs attribute. This is useful if you need to pass command line arguments to Node or Mono (not to the program being debugged).

Starting a debug session on Linux now opens a terminal with support for input/output.

TypeScript debugging now supports JavaScript source maps. Enable this by setting the sourceMaps attribute to true in the launch configuration. In addition, you can specify a TypeScript file with the program attribute. To generate source maps for your TypeScript files, compile with the --sourcemap option.

Debugging is now supported in folder-less workspaces
For example, you can debug when if a folder is not active (e.g., when you choose File, Close Folder or File, New Window). VS Code displays a purple status bar when you are in folder-less debug mode.

For exceptions thrown, via the code line marked in red, and for breakpoints, via the status bar.

Debugging UI

Here’s other debugging changes we made for this release.

  • A icon to collapse all variables has been added to the Variables tree.
  • You can now copy a variable’s value to the clipboard from the Variables tree.
  • Environment variables now work on all platforms.
  • VS Code no longer inadvertently hijacks an arbitrary terminal on OS X when starting a launch session. Only a terminal previously used for debugging is reused for a new session.
  • Arguments passed to the runtime or program being debugged can now contain spaces.
  • kbstyle(F9) and kbstyle(F11) work again.
  • Debugging works with UNC paths.
  • Better error messages are provided if Mono or Node is missing.
  • Support has been added for F# debugging on Mono on OS X and Linux

4.5 Tasks

We have defined three new problem matchers:

  • $jshint-stylish: To detect jshint problems produced by the stylish reporter.
  • $eslint-compact: To detect eslint problems produced by the compact reporter.
  • $eslint-stylish: To detect eslint problems produced by the stylish reporter.

Multiline problem matchers have been added to the task system to capture stylish output from several linting tools. You can see an example in Tasks.

You can now consistently redefine global properties per operating system and per explicit task. See operating specific values and task specific values for details.

A new property, suppressTaskName, can be specified globally, per operating system, or per task, to indicate whether the task name is added to the arguments when a task command is executed. See more details in the Appendix of Tasks.

4.6 Languages

4.6.1 Rust

Rust has been added as a supported language for colorization and bracket matching.

4.6.2 TypeScript

The TypeScript language service has been updated to TypeScript version 1.5.

4.6.3 JavaScript

New options allow you to turn off all semantic and syntax checks, useful if you prefer JSHint instead of the VS Code JavaScript validator.

  • javascript.validate.semanticValidation=[true|false] Use true to have VS Code report semantic errors (unassigned variables, etc. and all lint checks)
  • javascript.validate.syntaxValidation=[true|false] Use false to have VS Code report syntaX errors (missing brackets, etc.).

4.6.4 HTML

HTML auto closing of tags has now been removed and replaced with smarter IntelliSense on </.

4.7 CJK wrapping:

To get a better approximation of the Chinese-Japanese-Korean (CJK) character widths, we now measure half-width m and full-width m. This result is text with CJK characters renders with a monospace font which shouldn’t overflow the line and introduce horizontal scroll bars.

Chinese text

4.8 File Compare

File Compare applies to files in Working Files now too. A new global action, Files: Compare Opened File With, has been added to the Command Palette.

File Compare

4.9 Copy Path

To copy the path of any file or folder in the Explorer, right-click it and choose Copy Path.

Copy Path

A new global action, Files: Copy Path of the Active File, has been added to the Command Palette.

Palette Copy Path

4.10 Close Folder

The new menu item File, Close Folder will close the currently active folder and bring the workbench back into the “empty” state with a single, empty file opened. (If you haven’t enabled Auto Save, you’ll be prompted to save any pending changes in the active folder before it is closed.)

4.11 File Encoding

Set the file encoding globally or per workspace by using the files.encoding setting in User Settings or Workspace Settings.

files.encoding setting

You can view the file encoding in the status bar.

Encoding in status bar

Click on the encoding in the status bar to reopen or save the active file with a different encoding.

Reopen or save with a different encoding

Then choose an encoding.

Select an encoding

4.12 Settings

The JSON parser is now more fault tolerant. For example, if you have a trailing comma in settings.json, VS Code will no longer silently fail to apply your customized settings. We’ll still provide a visual indicator that there is an issue with the JSON. This example displays a red squiggly line on the last bracket, and a red box to the far right of Line 5.

JSON settings errors

4.13 UNC paths supported

With this release, you can now access Windows files and folders through UNC paths.

4.14 Working files watched

Files not inside the opened folder but inside Working Files are now watched for changes and updated when changed.

4.15 Linux 32-bit

VS Code is now available for 32-bit editions of Linux (download).

4.16 Other significant bug changes

We also fixed the following items.

  • 16481: Opening files from a UNC folder
  • 16457: Chinese characters not properly rendered on Linux
  • 16574: Encoding issues
  • 16500: $scope auto completes to $$scope
  • 16514: HTML tags are incorrectly auto completed
  • 16573: “CFBundleIdentifier” of “Visual Studio Code.app” should be changed from “com.github.atom-shell” to another unique identifier.

For a list of currently known issues, see our FAQ. You can view or report new issues here.

5 July 2015 (0.5.0)

Thank you again for using Visual Studio Code! With our second update, we have lots to share with you, so much that we’ll start with a quick summary for some of the key items:

  • Several updates to how we handle files, including file and folder filtering in the explorer, opening files via the command line at a specific line number, re-using an existing instance when you open multiple files, ability to control the size of the working files list.
  • Improved editor options that include support for removing trailing whitespace, improved search patterns with include/exclude filters.
  • Significant JavaScript updates including ES6 support, jsconfig.json, improved /// reference management, additional workspace settings
  • Git enhancements, including an integrated credential prompt, multi-line commit message support and improved control over auto-fetch
  • User-defined snippets support, and more built-in snippets for common languages, i.e., Dockerfiles, Python, and Rust.
  • Debugger enhancements including watch expressions, and improved Node.js breakpoint and source map support.
  • Other Stuff: Proxy support, auto-update enabled for Mac and Windows, notable bug fixes

This release is available now - see how to update to get the bits.

Read on to find out about the new features and learn how you can be more productive using VS Code.

5.1 Files

New file-based enhancements make it easier to link VS Code into your workflow with other tools, e.g. Unity, as well as improve the overall experience.

Note: In the Editor Options section below, we show how you can hide derived resources in the Explorer, update the size of the Working Files area and exclude files from Search.

New command line options: -r and -g

  • The -r (or --reuse-window) command line option forces opening a file or folder in the last active window. This is useful in cases where you want to quickly send a file from the command line into your workspace, without having to manage new windows each time. This also works with files that don’t exist - VS Code will simply open a new file as dirty in the last active window.

  • The -g (or --goto) command line option lets you open files at a specific line and column number. This is useful if you’re using another tool in your workflow and want VS Code to open an exact position within a file.<br/>The syntax is:<br/>code -g file1:<line>:<column?> file2:<line>:<column?> file3:<line>:<column?><br/>The column value is optional. As shown in the example, you can open multiple files in a single VS Code instance using the desired line and column position. Note that "-g" switch is mandatory for this feature, since : is a valid character in file names on some operating systems.<br/>
    Here’s how to open a file to line 10, column 17:<br/>code -g c:\mycode\HelloWorld.ts:10:17<br/>

**Tip:** If you combine -r and -g you can configure an external tool to open files on a specific line and column into your running VS Code instance! This was a popular request from the Unity user base.

Additional command line changes

When you pass multiple file paths to VS Code, they will all open in the same instance now. If some of the paths point to files that don’t exist, VS Code will open new files as dirty.

When you pass in command line arguments for the path to a folder, and also a file name, VS Code will open both the folder and file in a single VS Code instance. Previously we would open two (or more) VS Code instances. The usage case is that you want to open a specific file in a folder while still opening the folder in the side bar.

Note that you can use absolute paths or relative paths for the folder argument and the file argument. If you use a relative path for the file argument, it is relative to where you start VS Code (not relative to the folder argument).

This example opens the current folder and a specific file, HelloWorld.ts, in that folder (the file will be created as dirty if it doesn’t exist).

code . HelloWorld.ts

Mac dock support

You can now open files and folders by dropping them to VS Code, even if it is not yet running. In addition, when you drop multiple files on the dock while VS Code is already running, VS Code will not start separate instances for each, but instead will try to open them in one instance.

5.2 Editor options

We added more configuration options for files, explorer and search. Access them from File | Preferences.

Patterns syntax

To support several of the new Search and Editor options, we’ve introduced a lightweight pattern matcher. With a simplified set of patterns we support for specifying match patterns, you can use:

  • * to match one or more characters in a path segment
  • ? to match on one character in a path segment
  • ** to match any number of path segments ,including none
  • {} to group conditions (e.g. {**/*.html,**/*.txt} matches all html and txt files)
  • [] to declare a range of characters to match (e.g., example.[0-9] to match on example.0, example.1, …

Automatically trim trailing whitespace

By popular demand, we added the files.trimTrailingWhitespace setting that allows you to trim trailing whitespace whenever you save. This also works with autosave enabled.

Configure the size and behavior of Working Files

Two new settings give you more control over how files appear in the Working Files area - ideal for larger monitors!

  • The explorer.workingFiles.maxVisible setting allows you to configure the number of visible working files before a scrollbar appears (the default is 9).
  • The explorer.workingFiles.dynamicHeight setting lets you configure whether working files should dynamically adjust its height based on the number of elements inside. Set this to false if you don’t want the explorer jumping down when you add new working files. The default is true.

Hiding files and folders

The files.exclude setting lets you define patterns to hide files and folders from several places in VS Code like the explorer and search. Once defined, files and folders matching any of the patterns will be hidden.

**Tip:** This is really useful to hide derived resources files, like \*.meta in Unity, or \*.js in a TypeScript project. For Unity to exclude the \*.cs.meta files, the pattern to choose would be: "**/*.cs.meta"

Hide derived resources

If you use a language that compiles to another file at the same location of the source file, like TypeScript does to JavaScript, you often don’t want to see the files in the explorer or include them in search results. With the new filtering capabilities, you can easily set an expression to hide those derived files:

"**/*.js": { "when": "$(basename).ts"}

Such a pattern will match on any JavaScript file (**/*.js), but only if a sibling file with the same name and extension, *.ts in this example, is present. The result being Explorer will no longer show derived resources for JavaScript if they are compiled to the same location. All you have to do is configure this in the files.exclude setting. While we’ve used JavaScript for this example, the same technique can be used for other transpiled languages, like Coffee Script or Less/Sass, too.

Here’s an example of how JavaScript files are hidden using the "**/*.js": { "when": "$(basename).ts"} expression.

Hiding derived resources

Exclude files and folders from search

The search.exclude setting lets you configure additional files and folders to exclude from full text searches and from quick open, besides the file.exclude setting. This uses the patterns syntax (discussed below).

Note: This is a breaking change, as it replaces search.excludeFolders, so be sure to update your settings!

Search leveraging patterns

To let you define powerful patterns for includes and excludes when you run searches, we added glob pattern support to the search box too. You can enable glob pattern search by clicking on the little icon in the include and exclude box.

Once you click on the pattern icon, you have access to the pattern reference.

Search patterns

Note: You can still use wildcards without enabling glob pattern support. Things like *.js to search in all JavaScript files still work. Once you enable glob pattern syntax, keep in mind that you need to use **/*.js to search across all directories of your project!

5.3 JavaScript

We’ve made a lot of changes for JavaScript development in this release.

Breaking Changes

A change like this comes with a few breaking changes: We deprecated some advanced configuration settings: validate.scope, validate.baseUrl, validate.target, validate.module, validate.noLib. We’re providing support for jsconfig.json to offset these settings no longer being supported.

Support for ES6

A popular request since our launch has been support for ES6 (ECMAScript 6, the latest update of JavaScript targeting ratification in June 2015). You can expect VS Code to understand the new ES6 syntax elements and their semantics.

Note that super-references in deriving object-literals is still on our plate; currently if you try this in VS Code you’ll receive a faulty compile error, which you can suppress with the _surpressSuperWithoutSuperTypeError: [true|false] option.

**Tip:** A good overview of the new ES6 features can be found here: https://github.com/lukehoban/es6features

Projects - jsconfig.json

You can create a JavaScript project by dropping in a jsconfig.json file. It’s a subset of tsconfig.json, and it allows you to define what files are part of a project, and what compiler options to use.
Same as in tsconfig.json if no “files” property is present in a jsconfig.json, we default to including all files in the containing directory and subdirectories. When a “files” property is specified, only those files are included.

jsonconfig.json

This means you don’t need to use /// references anymore. As the project defines the file set, VS Code just knows what files and symbols are part of your project. As an example, you can just drop a new .d.ts file into your project folder and VS Code will pick it up automatically.

Note: In the Editor Options section, we discuss how you can hide derived files in the Explorer window, e.g. *.js files generated from *.ts sources. In the Debugging section, we discuss support for JavaScript Source Maps and minified/uglified JavaScript debugging.

Shebang coloring

We improved colorization for shebang #!, as shown in the first line here:

Shebang coloring

5.4 Snippets

VS Code launched with snippet support, and we’ve added some notable enhancements in this release.

User-defined snippets

To add your own code snippets, use the newly added User Snippet action available by File | Preferences. This action opens a language selection dialog. Selecting a language will open the snippets for the file language. Enter your snippets directly in the editor.

**Tip:** Changes are picked up on save (there’s no need to restart VS Code).

This is an example of a snippet file:

{
    "Node Require" : {
        "prefix": "require",
        "body": [
            "var ${module} = require('${module}');",
            "$0"
        ],
        "description": "Node require statement"
    }
}

Each property in the object represents a snippet.

  • body is what is inserted when the snippet is selected.
  • description is shown as additional information.
  • prefix is what IntelliSense will use as a label and to filter against.

The body format follows the TextMate template syntax (https://manual.macromates.com/en/snippets), with the following constructs supported:

  • plain text
  • placeholders with identifiers ${id: text}
  • simple tab placeholders $0, $1, …
  • nested placeholders ${id1: some text ${id2: nested text} }

We have also added some more snippets out of the box for Dockerfiles, Python, and Rust.

5.5 Git

We updated our Git support by delivering several of the most requested features.

Credential prompt

Many users have reported that the Git tools can be non-responsive. This is typically a result of the Git action being blocked by an authentication prompt. With this update, when Git requires credentials you will see a pop-up, prompting you to enter the required credentials.

Credential prompt

**Tip:** If you don’t want to always enter your credentials, consider using a credential helper.

Multi-line commit

Previously, commit messages in VS Code supported only a single line of text. We now support multiple lines of text in your commit message. (Type kbstyle(Ctrl+Enter) to finish the commit message, or kbstyle(Enter) to add a new line to the message.)

Multiline commit message

Multiple file selection

Multiple selection is now enabled in the Git view, meaning you can stage/unstage or commit multiple files at the same time.

Select multiple files

Auto fetch control

There is now an action to enable/disable Git auto fetch in the dropdown menu of the Git view. This is handy if you don’t have a credential helper and don’t want to get prompted for authentication all the time.

5.6 Debugging

Debugging is core to the workflow enabled by VS Code, and with this release we support several additional scenarios.

Improved launch.json generation

We are now consulting package.json for a main attribute when generating launch.json. The result is the generated launch.json is more precise.

Watch expressions

We added a new debug pane for watch expressions. You are able to add, rename or remove watch expressions from the Debug view. Based on the focused stack frame, watch expressions are reevaluated whenever the debug target has stopped. It is also possible to add an expression to watch using the editor context menu.

Watch expressions

Ability to edit during debug

The workbench is no longer in read-only mode when debugging.
However, VS Code does not yet support ‘hot code replacement’, so edited code is not automatically picked up by the debugger
but a new ‘Restart Session’ action helps to improve the experience.

Improved Node breakpoint handling

Node does not parse source files completely on load, rather it delays parsing of closures (e.g. callbacks) until their code is first hit. As a consequence, breakpoints set on callbacks are sometimes not registered for the line requested but instead register for the next possible line in already-parsed code. To avoid confusion, we now show breakpoints at the location where node thinks the breakpoint is. In the breakpoint view, these breakpoints are shown with this notation:

request lineactual line

Here’s an example:

Node breakpoints

This breakpoint validation occurs when a session starts and the breakpoints are registered with node, or when a session is already running and a new breakpoint is set. In this case, the breakpoint may “jump” to a different location. After node.js has parsed all the code (e.g,. by running through it), breakpoints can be easily re-applied to the requested locations with the Reapply button in the breakpoint view’s header. This should make the breakpoints “jump back” to the requested location.

Activate / deactivate breakpoints

You can now toggle the active breakpoints.

Toggle active breakpoints

JavaScript source maps

If generated (transpiled) JavaScript files do not live next to their source, you can help the VS Code debugger locate them by specifying the outDir directory in the launch configuration. Whenever you set a breakpoint in the original source, VS Code tries to find the generated source, and the associated source map, in the outDir directory.

In-lined source maps (a source map where the content is stored as a data url instead of a separate file) are now supported, although in-lined source is not yet supported.

Minified debugging

Debugging minified/uglified JavaScript is now supported.

5.7 Other stuff

Output toggling

A new action was added that allows to toggle the output window. When output is not showing, it will just show output. But when output is showing, it will restore the previous editor you’d been using. This allows to quickly check the output and then quickly return to the work you did before. The action replaces the previous “Show Output” action, so by default the keybinding for output toggling is Ctrl+Shift+U (Cmd+Shift+U on Mac).

Auto-update enabled for OS X and Windows

With this update, future updates will be automatic for OS X and Windows users (we don’t support auto-updates for Linux). If you want to opt out of auto-updates, see instructions here.

Proxy Support

Http requests for package/project/bower.json IntelliSense as well as fetching schemas and for Send-a-Smile now can go through a proxy server.

To configure a proxy either:

  • Set the http_proxy and the https_proxy environment variables before starting VS Code.
  • Set the http.proxy user setting.

Note: VS Code supports http and https proxies, but not SOCKS proxies.

Notable Bug Fixes

  • 16480: Git push/pull not working
  • 16782: Fonts Are Blurry
  • 17223: SourceMap debugging doesn’t work with inlined source map
  • 17079: OS X Poor Scrolling in Explore Sidebar

For a list of currently known issues, see our FAQ. You can view or report new issues here.

6 August 2015 (0.7.1)

Hi,

It’s time to update VS Code again :) This is a smaller update in terms of raw added features – but have no fear we are not slacking off - behind the scenes we are working hard to add plug-in support to VS Code. Paired with this release we have also made a number of updates to our documentation.

Read on to find out what’s new…

6.1 Improved Documentation

With this release we updated almost all of our documentation to help you get more out of VS Code.

We broke down the content into four sections:

  • Overview - A quick summary of all the documentation including a video overview
  • Editor - An introduction to VS Code itself from editing all the way to debugging and tasks
  • Languages - Walkthroughs on how to get the best out of VS Code when using specific languages e.g. JavaScript

Updated docs for VS Code

**Tip:** You can search our site via the search box in the header.

6.2 Debugging

6.2.1 node.js: Large data stucture improvments

In previous versions of VS Code, debugging would stall (and timeout) when stepping through code that used large Arrays or Buffers. In this version the VS Code debugger treats large data structures (Arrays and Buffers) in a more scalable way and should no longer timeout. The same should be true for drilling into large data structures in the variables or watches view section.

As a consequence, the debugger now renders the contents of Arrays and Buffers in chunks.

Chunked Arrays

Note: These improvements require version 0.12.x of node.js (these improvements are not yet supported for io.js).

6.2.2 node.js: Stable breakpoints

For performance reasons node.js parses the functions inside JavaScript files lazily on first access. As a consequence, breakpoints don’t work in source code that hasn’t been seen (parsed) by node.js.

Since this behavior is not ideal for debugging, VS Code now passes the --nolazy option to node.js automatically. This prevents the delayed parsing and ensures that breakpoints can be validated before running the code (so they should no longer ‘jump’).

**Tip:** If you have to attach VS Code to an already running node process, be aware that this node.js runtime probably wasn’t started with the --nolazy flag.

6.2.3 Variable support in launch.json

VS Code now supports variables in the launch.json file in the same way as in tasks.json (see Tasks).

6.2.4 Run to cursor

You can now run up to the cursor location with a new action included in the context menu.

6.3 Tasks

We did a significant review of the Tasks documentation with this update and have included several examples of using tasks.

We also now support automatic detection of tasks in a gruntfile. This works the same as our support for the Gulp and Jake task runners (see Tasks).

6.4 Markdown

We added a full overview of how to use VS Code with Markdown files.

We now show you how to:

  • leverage built-in snippets
  • configure preview with custom CSS
  • use Auto Save for live updates
  • use tasks to compile to HTML

6.5 JavaScript

In our JavaScript documentation we’ve added topics covering:

  • JavaScript projects with jsconfig.json
  • ES6 support
  • Configuring linters such as JSHint and ESLint
  • Rich Editing Support
  • IntelliSense

We also updated the quick fix code action. Add /// reference for typing file was renamed because /// references are no longer needed to get IntelliSense from .d.ts files. The action is now called Download type definition for some typing file and it downloads the .d.ts file only.

We added the ability to exclude files and folders from a project via the addition of an exclude property in the jsconfig.json. This is useful when you want to exclude folders with generated JavaScript code.

{
    "compilerOptions": {
        "target": "ES6"
    },
    "exclude": [
        "node_modules"
    ]
}

Finally, one key bug we fixed in this update was unlocking the ability to work with Ember.js/ES6/AMD projects - previously VS Code would crash with these large projects.

6.6 HTML

We improved our HTML formatter in this release and updated the HTML documentation.

6.7 JSON

We improved the JSON formatter, specifically formatting with comments and formatting ranges.

In the JSON documentation we now include examples of:

  • Working with JSON comments
  • IntelliSense and Schema validation
  • Quick navigation
  • Hovers and Toggle Values
  • Configuring JSON Schemas

6.8 CSS, Less and Sass

We updated our CSS, Less and Sass documentation to provide examples of how to work with CSS in VS Code.

This includes sections on:

  • CSS IntelliSense
  • Emmet Snippet support
  • Syntax highlighting and Color preview
  • Goto symbol & Hover support
  • Goto declaration & Find references
  • Using tasks to transpile Sass and Less into CSS
  • Customizing CSS settings

6.9 PHP

We added a set of common snippets for PHP. To access these hit kb(editor.action.triggerSuggest) to get a context specific list.

PHP Snipets

6.10 C#

We have moved to the latest OmniSharp version 1.1.0.

We also added in early support for quick fixes (aka. lightbulbs) via Roslyn and NRefactory.

Quick fixes are automatically computed when you put the cursor onto a marker; they can also be requested by pressing kb(editor.action.quickFix).

Quick Fix - Marker

In the image below you can see the prompt to extract a method from the current selection:

Quick Fix - Selection

6.11 Dockerfile

We added a new document that covers our Docker support.

Our Docker support includes:

  • Dockerfile - Hovering over instructions
  • Docker-compose.yml - Hovering over keys and images, rule completion, image name completion

6.12 Swift

We added syntax coloring and a set of common snippets.

6.13 Groovy

We added syntax coloring and a set of common snippets.

6.14 Notable Bug Fixes

As always we fixed many issues.

Here are a few of the notable ones from the public bug tracker:

  • 17915: VS Code crashes with large emberjs/es6/amd project
  • 17427: Git cannot be found if installed into a non-default location
  • 17947: Open with encoding Windows 866 doesn’t work
  • 18094: Wrong “duplicate identifier” error in node files when using “exports”*

7 September 2015 (0.8.0)

Hi,

It’s that time again – our September update is ready for VS Code.

7.1 Important Updates and Breaking Changes

Before we get into all of the exciting new stuff, there are a couple of key changes with this update that we don’t want you to miss.

7.1.1 New Windows Setup

We adopted a new installation and update framework for Windows based on Inno Setup.
This fixes many Windows integration issues and streamlines the update story.

Note: You will see a two stage update as a result of the change to the new installer. First to version 0.7.20 to bootstrap the new installer and then to the 0.8.0 release version. The new installer will prompt you during installation. Continue through the setup dialog to install VS Code 0.8.0.

**Tip:** You will need to close any currently open command windows to pick up the new PATH setting.

7.1.2 Renamed VS Code Settings Folder

We renamed the top level .settings folder to .vscode to make it clear that this folder contains VS Code specific configurations and to avoid conflicts with other IDEs who may also use a folder named .settings (e.g. Eclipse).

When you update to version 0.8.0, VS Code will rename the folder to the new name and inform you if you had any files in a .settings folder.

7.2 Additional Themes

VS Code is now able to apply TextMate syntax color themes (.tmTheme). We picked some themes from (http://colorsublime.com/) and made them available under File | Preferences | Color Theme. In one of the next releases, users will be able to extend this list with their own favorite themes.

Open the Color Theme picker with File | Preferences | Color Theme and use the up and down keys to change the selection and preview the themes.

Color Themes

7.3 Debugging - No Mono Dependency for Node

We have ported the implementation of the Node.js debugging support from C#/Mono to TypeScript/Node.js, eliminating our Mono dependency for debugging Node.js applications on OSX and Linux.

7.4 Debugging - Debug Console

In this release, we included a preview of the Debug Console for easy evaluation of expressions. The Debug Console can be opened using the Open Console action at the top of the Debug view or using the Debug: Open Console action in the Command Palette.

Debug Console

7.5 Languages - JavaScript Linting as you Type

VS Code now provides support for ESlint and JSHint. If enabled, the JavaScript code is validated as you type and reported problems can be navigated to and fixed inside VS Code.

To enable one of the linters do the following:

  • Install the corresponding linter globally or inside the workspace folder that contains the JavaScript code to be validated. For example using the command lines: npm install eslint --save-dev or npm install jshint --save-dev, respectively.
  • Enable eslint or jshint via the corresponding VS Code settings "eslint.enable": true or "jshint.enable": true, respectively.
  • Optionally disable VS Code’s built-in JavaScript validation via the setting "javascript.validate.enable": false.

Try it out by opening a JavaScript file and adding a problem that should be detected by the enabled linter. VS Code shows problems inside the editor and in the status bar.

7.6 Languages - TypeScript 1.6 Support

Note: At this time, TypeScript 1.6 should be considered experimental so proceed at your own risk. :)

VS Code uses TypeScript 1.5 in the box. If you want to use a newer version of TypeScript, you can define the typescript.tsdk setting. The value of this setting is the absolute path to the lib folder of a TypeScript installation. This folder contains the file tsserver.js and the corresponding lib.*.d.ts files. Refer to this blog post for how to install the nightly builds of TypeScript.

7.7 Languages - TSX

We now support colorizing TSX (TypeScript JSX) files. To get full language support for TSX files, you need to install the latest TypeScript 1.6 version and configure VS Code to use it with the typescript.tsdk setting, as described above.

To learn more about how to use TSX with TypeScript refer to the TypeScript TSX Wiki page.

7.8 Languages - JSX Colorization

We now support colorizing JSX files.

7.9 Languages - C# on Omnisharp 1.1.1

We have moved to the OmniSharp version 1.1.1 (OmniSharp releases). This version of OmniSharp will happily work with DNX Beta7 but note that on Linux and Mac there is not yet support for using CoreCLR as a development platform.

7.10 Git - Undo Last Commit

There is a new Undo Last Commit action which will let you undo your previous commit, keeping the changes in the working folder.

7.11 Tasks - echoCommand Property

A new property echoCommand has been added to the global and task specific sections of the tasks.json file. If set to true, the executed command is echoed to the task’s output view. This is useful when you are configuring tasks and you want to see the full command VS Code is running.

7.12 Notable Bug Fixes

As always we fixed many issues.

Here are a few of the notable ones from the public bug tracker:

  • 18617: C# IntelliSense suggestions only come up after error checking, making them slow over time
  • 17259: Cannot control installation location
  • 18603: Duplicate icon on Windows 10
  • 17159: Cannot open a file with spaces in its name from command line

8 October 2015 (0.9.1)

Hi,

It’s that time again – our October update is ready for VS Code.

8.1 Persistent (update to update) location for Customizations

Previously we did not have a location we respected across updates. It’s true that we did have a location for user settings but as we get closer to our final update story we added a new location. In the future, we will (gracefully) move all user settings here.

The new location is .vscode/extensions under your user directory.

Depending on your platform, this folder is located here:

  • Windows %USERPROFILE%\.vscode\extensions
  • Mac $HOME/.vscode/extensions
  • Linux $HOME/.vscode/extensions

As this location is under your user directory, the content is persisted across VS Code updates. This is just the start and we plan to use this location more in future updates.

8.2 Yo Code - Streamlined Customizations for VS Code

We re-purposed the Yeoman generator we used for the VS Code Node.js sample generator-code and we are now using this to make creating common customizations easier.

In this release of the generator, we have the ability to create two common customizations:

  1. Additional color themes
  2. Syntax highlighters/bracket matchers

In the future, we’ll add other options for rich customization of VS Code.

If you have a TextMate color theme (.tmTheme) or a TextMate language specification (.tmLanguage), you can bring them into VS Code using the ‘code’ Yeoman generator.

Install and run the code Yeoman generator as follows:

  1. npm install -g yo
  2. npm install -g generator-code
  3. yo code

yo code

The Yeoman generator will walk you through creating your customization prompting for the required information. Once the generator is finished, copy the generator’s output folder to a new folder under the .vscode/extensions folder and restart VS Code to use the new features.

In the future you will be able to publish these customizations to an external gallery to share them with the community.

**Tip:** If you want to share your customization with others in the meantime, you can simply send them a copy of the output from the generator and ask them to add it under their .vscode/extensions folder.

8.3 Customization - Adding Language Colorization & Bracket Matching

Using the ‘code’ Yeoman generator you can add TextMate language specification files (.tmLanguage) to your VS Code installation to get syntax highlighting and bracket matching.

A good place to look for existing TextMate .tmLanguage files is on GitHub. Search for a TextMate bundle for the language you are interested in and then navigate to the Syntaxes folder. The ‘code’ Yeoman generator can handle either .tmLanguage or .plist files. When prompted for the URL or file location, pass the raw path to the .tmLanguage file e.g. https://raw.githubusercontent.com/textmate/ant.tmbundle/master/Syntaxes/Ant.tmLanguage.

yo code language

The generator will prompt you for other information such as a unique name (this should be unique to avoid clashing with other customizations) and the language name, aliases and file extensions.

When the generator is finished, copy the complete output folder to a new folder under .vscode/extensions. When you restart VS Code, your new language will be visible in the language specifier dropdown and you’ll get full colorization and bracket/tag matching for files matching the language’s file extension.

ant language

8.4 Customization - Adding Themes

You can also add new TextMate theme files (.tmTheme) to your VS Code installation.

ColorSublime has hundreds of existing TextMate themes to choose from. Pick a theme you like and copy the Download link to use in the Yeoman generator. The ‘code’ generator will prompt you for the URL or file location of the .tmTheme file, the theme name as well as other information for the theme.

yo code theme

Copy the generated theme folder to a new folder under .vscode/extensions and restart VS Code.

Open the Color Theme picker theme with File | Preferences | Color Theme and you can see your theme in the dropdown. Arrow up and down to see a live preview of your theme.

my theme

While building this, the VS Code team contributed a Pull Request to node-oniguruma that results in a nice performance improvement when colorizing/tokenizing. Both the Atom and VS Code IDEs profit from this improvement.

8.5 Debugging - Performance

We improved stepping performance by loading the scopes and variables of stack frames lazily. This improvement is based on a protocol change that affects all debug adapters.

8.6 Debugging - Pre-Launch Task

In a project’s launch configurations (launch.json), you can now use the preLaunchTask attribute to specify a task to run before a debug session starts.

For example, with this option you could make sure that your project is built before it is launched in the debugger. If the task results in errors, an error message warns you and you can decide to either fix the errors or continue launching the debugger.

8.7 Debugging - Debug Console

We have made many improvements to the Debug Console:

  • Text selection is now supported
  • Better colors for improved visibility
  • Richer context menus
  • Expansion of elements is preserved between sessions

Debug Console

8.8 Languages - C#

The status of the OmniSharp server is now using a new language status indicator in the lower right corner. This makes it much easier to see the context OmniSharp is running under and any issues.

Language Status indicator

8.9 Languages - TypeScript

We now ship with TypeScript 1.6.2. You can learn more about the latest release of TypeScript at Announcing TypeScript 1.6.

We simplified defining a task to run the TypeScript compiler in watch mode.
You can now configure the watch property in the tsconfig.json and then define a task as follows:

{
    "version": "0.1.0",
    "command": "tsc",
    "isShellCommand": true,
    // define the task to be a watching task
    "isWatching": true,
    // use the standard tsc in watch mode problem matcher to find compile problems in the output.
    "problemMatcher": "$tsc-watch"
}

8.10 Languages - Markdown Preview

Markdown preview was improved so that embedded code stands out more clearly and the overall font sizes and spacing were optimized. In addition
there is a new action to quickly open the Markdown preview to the side (Markdown: Open Preview to the Side).

open preview side

8.11 Runtimes - Unity

We’ve added colorization for Unity shader files.

unity shader colorization

8.12 Files - New Settings

We added two new configuration options to control how files open and folders reopen between sessions.

The window.openFilesInNewWindow setting controls if files should open in a new window instead of reusing an existing VS Code instance. By default, VS Code will
open a new window, e.g. when you double-click on a file outside VS Code or open a file from the command line. Set this to false to reuse the last
active instance of VS Code and open files in there.

The window.reopenFolders setting tells VS Code how to restore the opened windows of your previous session. By default, VS Code will
reopen the last opened folder you worked on (setting: one). Change this setting to none to never reopen any folders and always start with an
empty VS Code instance. Change it to all to restore all folders you worked on. This will reopen all the windows with folders of your previous session.

8.13 Notable Bug Fixes

As always we fixed many issues.

Here are a few of the notable ones from the public bug tracker:

  • 18998: newly added files not honored by tsconfig.json
  • 18692: Changes to tsconfig.json not updated immediately
  • 19239: Detaching from Unity Results in a Unity Crash

Other issues we’ve fixed:

  • JSON schemas support external references.
  • The CSS tooling now supports CSS3 identifier escaping.
  • Node.js Debugger: In 0.9.0, we focused on fixing the problems that resulted from the introduction of a new implementation of the Node.js debugger in VS Code 0.8.0.
    You should no longer see empty CALL STACK, VARIABLES and WATCH views.

9 February 2017 (version 1.10)

Update 1.10.2: Adds the 1.10 translations and addresses a handful of issues.

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


9.1 February Release Summary

Welcome to the February 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:

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

  • Editor - Word wrap settings simplification, manually trigger Save actions, new cursor styles.
  • Workbench - Configurable window title, run either selected text or entire file from the Integrated Terminal.
  • Languages - TypeScript 2.2, disable color preview decorators, better link navigation in Markdown.
  • Debugging - Launch debugger using just the keyboard, new variable syntax.
  • Tasks - Run tasks in separate terminals, new ${lineNumber} variable.
  • Extension Authoring - Pluggable SCM provider, Modal message dialogs, provide language specific settings.

**Tip:** 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.

9.2 Editor

9.2.1 Preview: Minimap

A Minimap gives you a high level overview of your source code which is very useful for quick navigation and code understanding. To enable VS Code’s Minimap, set "editor.minimap.enabled": true to turn on the rendering of a Minimap for the current file.

Minimap

The screenshot above is on a Surface Book (high DPI display). Based on the devicePixelRatio (for example, regular or retina/high DPI displays), the Minimap will render characters either at 4x2 pixels or at 2x1 pixels.

For those that would prefer a more schematic representation for the current file, there is editor.minimap.renderCharacters that can be set to false to render blocks instead of characters in the Minimap.

Here it is on a regular display:

Minimap Blocks

This milestone we have focused on rendering the characters in a fast, incremental way (we reuse as many pixels as possible from the previous frame when rendering a new frame). We plan to add more useful information to the Minimap in the future, for example current selection, find matches, Git diff annotations, etc.

9.2.2 Preview: Drag and Drop selected text

You can now use the mouse to drag and drop selected text inside the editor. This feature is disabled by default and you can turn it on by set editor.dragAndDrop to true.

Drag and drop

Please note we don’t support drag-and-drop across editors or across different applications at the moment.

9.2.3 Copy with syntax highlighting

You can now copy selected text to the Clipboard with syntax highlighting. It can be very useful when you paste the content into another application, for example, Outlook, and the content pasted into the application still has the correct formatting and colorization.

Technically, we add a new entry for HTML content into the Clipboard so even if the target application doesn’t support pasting rich text, the pasting will still work.

Copy with syntax highlighting

Copying plain text to the Clipboard is easy and straight-forward but copying text with syntax highlighting has to pay the price of rendering based on the Theme you are using, so in order to make sure this feature doesn’t slow down VS Code noticeably, we turn it off if you are copying a selection which contains more than 65536 characters.

If Copy and Paste with correct format and colors is your top priority, so you can always manually run the new command editor.action.clipboardCopyWithSyntaxHighlightingAction or even bind it to kbstyle(ctrl/cmd+c) so you don’t need to worry if the selection length reaches the limit.

9.2.4 Word wrap settings redesign

In VS Code 1.9, we’ve changed the Toggle Word Wrap action to persist to User settings. The change was received with mixed feelings by our community, so for VS Code 1.10 we have rolled back that change and the action will only temporarily affect the current focused editor.

The change also started a healthy discussion around the difficulty of configuring the editor’s wrapping behavior. We therefore decided to deprecate editor.wrappingColumn (with its -1, 0, >0 cases) in favor of editor.wordWrap.

Here are the new word wrap options:

  • editor.wordWrap: "off" - Lines will never wrap.
  • editor.wordWrap: "on" - Lines will wrap at viewport width.
  • editor.wordWrap: "wordWrapColumn" - Lines will wrap at the value of editor.wordWrapColumn.
  • editor.wordWrap: "bounded" - Lines will wrap at the minimum of viewport width and the value of editor.wordWrapColumn.

We also changed the default and now VS Code ships with editor.wordWrap: "off".

In this release, we added support for language specific default settings and we now turn on word wrap by default for Markdown files.

9.2.5 Manually trigger save actions

You can now save an editor via kb(workbench.action.files.save) even if the file is not dirty and extensions which perform actions on save will be triggered. This allows you to trigger Format on Save even if the file is not dirty.

9.2.6 New cursor styles

Thanks to PR #14237, there are three more cursor styles available: 'line-thin', 'underline-thin' and 'block-outline'.

9.3 Workbench

9.3.1 Configurable Explorer key bindings

By popular demand, you can now configure the key bindings for most of the commands in the File Explorer and OPEN EDITORS view.

The following commands could already be assigned prior to version 1.10 in the File Explorer:

  • explorer.newFile - Create a new file
  • explorer.newFolder- Create a new folder

New commands that work in both the File Explorer and OPEN EDITORS view

  • explorer.openToSide - Open to the side
  • copyFilePath - Copy path of file/folder
  • revealFileInOS - Reveal file in OS

New commands that only work in the File Explorer:

  • filesExplorer.copy - Copy a file from the File Explorer
  • filesExplorer.paste - Paste a file that was copied from the File Explorer
  • renameFile - Rename a file/folder in the File Explorer
  • moveFileToTrash - Move a file/folder to trash from the File Explorer
  • deleteFile - Bypass trash and delete a file/folder from the File Explorer
  • filesExplorer.findInFolder - Find inside a folder from the File Explorer

In addition to these commands, the following contexts are introduced for key bindings:

  • filesExplorerFocus - Keyboard focus is inside the File Explorer
  • openEditorsFocus - Keyboard focus is inside the OPEN EDITORS view
  • explorerViewletFocus - Keyboard focus is in either the File Explorer or OPEN EDITORS view

9.3.2 Configurable tree/list key bindings

We introduced new commands (see below) to make working with trees and lists UI elements in VS Code more configurable for keyboard centric users.

Here is a list of new commands that will work in every tree and list:

Command Keyboard shortcut
list.focusUp kbstyle(Up Arrow) (additionally on macOS: kbstyle(Ctrl+P))
list.focusDown kbstyle(Down Arrow) (additionally on macOS: kbstyle(Ctrl+N))
list.focusFirst kbstyle(Home)
list.focusLast kbstyle(End)
list.focusPageDown kbstyle(PageDown)
list.focusPageUp kbstyle(PageUp)
list.collapse kbstyle(Left Arrow) (additionally on macOS: kbstyle(Cmd+Up Arrow))
list.expand kbstyle(Right Arrow)
list.clear kbstyle(Escape)
list.select kbstyle(Enter) (additionally on macOS: kbstyle(Cmd+Enter))
list.toggleExpand kbstyle(Space)

With these new commands, we now consistently support kbstyle(Ctrl+P) and kbstyle(Ctrl+N) to navigate up and down in trees and lists on macOS.

For example, on macOS to change the command to open from the File Explorer to be kbstyle(Enter) (which normally brings you into rename mode), configure:

{
    "key": "enter",
    "command": "list.select",
    "when": "filesExplorerFocus"
}

9.3.3 Configurable window title

We introduced a new setting window.title that can be used to change the window title based on the active editor opened.

You can compose the title with the following variables (shown here for /Users/Development/myProject/myFolder/myFile.txt):

  • ${activeEditorLong} - /Users/Development/myProject/myFolder/myFile.txt
  • ${activeEditorMedium} - myFolder/myFile.txt
  • ${activeEditorShort} - myFile.txt
  • ${rootName} - myProject
  • ${rootPath} - /Users/Development/myProject
  • ${appName} - Visual Studio Code
  • ${dirty} - a dirty indicator if the active editor is dirty
  • ${separator} - a conditional separator (" - “) that only shows when surrounded by variables with values

The window.title has the following defaults:

  • Windows/Linux: ${dirty}${activeEditorShort}${separator}${rootName}${separator}${appName}
  • macOS: ${activeEditorShort}${separator}${rootName}

Note: We no longer support window.showFullPath in favor of the window.title setting. The variable ${activeEditorLong} will give you the full path.

9.3.4 Restore Zen Mode

Per user request, we have added a zenMode.restore setting to control if a window should restore to Zen Mode if it was exited in Zen Mode.

9.3.5 Theme configurations in settings

New settings have been added that define the currently active Color and File Icon theme:

{
  // Specifies the color theme used in the workbench.
  "workbench.colorTheme": "Default Dark+",

  // Specifies the icon theme used in the workbench.
  "workbench.iconTheme": null
}

By placing the options in the workspace settings, you can now have a different theme per workspace. These used to be stored in a separate location but now they are in your settings files.

To change a theme, you can still use the theme selection dialog in the Preferences menu with the Preferences: Color Theme and Preferences: File Icon Theme commands.

The terminal now creates links for URLs and text that looks like a path. These links will either be opened in a browser or the editor when triggered respectively.

terminal link

9.3.7 Run in terminal commands

In previous releases, there was the single command workbench.action.terminal.runSelectedText which sent text to the terminal. This would send either the selection if there was one, or the entire file if not. This caused some issues as users would accidentally run entire files when they were expecting to run the current line if there was no selection. Running a file would also not work in some shells as the shell would interpret the text in chunks, not as a whole. To improve these scenarios, there are now two commands with distinct behaviors:

  • workbench.action.terminal.runSelectedText: Sends the selection if there is one to the terminal, otherwise sends the current line.
  • workbench.action.terminal.runActiveFile: Sends the file path of the active file to the terminal (in most shells this will execute the file).

9.3.8 Display chord key bindings in menus

In previous releases, you might have noticed that a menu entry would not show a keyboard shortcut even though you had a key binding assigned. The reason was that some key bindings (for example multiple key chords) cannot be displayed as keyboard shortcuts in menus (including context menus).

As a workaround, we now show those key bindings as part of the menu label:

menu

9.3.9 Search results count

We now show the total number of files and matches for a search in the Search View.

Search results count

9.3.10 Improving search speed going forward

We’ve been looking into how to make our file search even faster. We explored two alternatives: Silver Searcher and ripgrep. If your are interested in our findings, have a look at our write-up. It’s a good read.

9.4 Languages

9.4.1 TypeScript

VS Code now ships with TypeScript 2.2. This release includes a number of new language features, bug fixes, and other enhancements.

TypeScript 2.2 also brings support for a number of new quick fixes, including:

  • Add missing import
  • Add missing property
  • Add forgotten this to variable
  • Remove unused declaration
  • Implement interface or abstract class

9.4.2 Auto JSDoc comments

VS Code will now provide a JSDoc comment template for JavaScript and TypeScript functions when you type /**:

JSDoc autofill

9.4.3 HTML

Document symbols are now available also for HTML, allowing you to quickly navigate to DOM nodes by id and class name.

Press kb(workbench.action.gotoSymbol) to bring up the symbol in file.

HTML document symbols

Thanks to Cody Hoover for the contribution.

9.4.4 CSS

The CSS, LESS and SCSS color preview decorators can now be disabled in the settings:

  "css.colorDecorators.enable": true,
  "scss.colorDecorators.enable": true,
  "less.colorDecorators.enable": true

9.4.5 Jade

Jade is now known as Pug. Nothing has changed but the language label. The language id is still jade and the .jade file extension is still served.

9.4.6 Vue

While Vue.js files may look like HTML files, they are much more than that. For that reason, the .vue file extension is no longer associated with HTML by default. However we do recommend you use a Vue.js specific extension for language support and the vetur extension is a good choice.

9.4.7 Go, Make, YAML, Markdown

These languages are now using the new support for default configuration settings per language (see Default Language specific editor settings below). For Go, Make, and YAML, the default settings configure kbstyle(Tab) behavior as defined by these languages. For Markdown, the default enables word wrapping and disables quick suggestions.

Links to Markdown files that include a fragment will now try to open the file at the corresponding header:

* [Section](#header)
* [Another file](./other_file.md#header)

# Header
...

This allows quickly navigating documentation directly within the VS Code editor.

9.5 Debugging

9.5.1 Column breakpoints

As per popular request, we now support setting breakpoints on an editor column.
This helps debugging code that contains multiple statements on a single line which typically occurs with heavily chained promises or minified source.
A column breakpoint can be set using kb(editor.debug.action.toggleColumnBreakpoint) or via the context menu during a debug session.

column

Note: A debug extension backend will adjust the location of breakpoints to ‘possible’ locations. This might cause breakpoints to move when starting a debug session or when setting a column breakpoint while a session is active.

9.5.2 Improved Exception experience

To improve the visibility of exceptions as they occur during debugging, we now show the exception directly in the editor with a peek UI:

launch

This issue was raised because sometimes users were not aware that an exception was raised (especially in library code). Another motivation for the introduction of the peek UI was to make it easy to show many more exception details.

9.5.3 Ability to select and start a launch using keyboard

The option to launch debug configurations using just the keyboard (no mouse gesture necessary) was added, as per this request. It works similarly to running tasks, with an ability to launch a debugging session from the Command Palette. The keyword 'debug ' or the command Debug: Select and Start Debugging from the Command Palette is used to select and launch a configuration from launch.json.

launch

9.5.4 New variable syntax

Starting with this release, we now support the colon character ‘:’ as a prefix separator in variable names (and we have deprecated the ‘.’). With this change, the new (and preferred) syntax for ‘env’, ‘command’, and ‘config’ variables becomes ${prefix:id}.

This makes command variables (where the command ID itself uses ‘.’) much more readable:

"processID": "${command:extension.node-debug.pickProcess}"

9.5.5 Precondition based on debugger type

It is now possible to have a precondition based on the current debug type. Preconditions can be used when defining keyboard shortcuts or when registering new commands as an extension.

Here’s an example of a shortcut that will only be enabled while you are debugging with type ‘node’:

{ "key": "f6", "command": "workbench.action.debug.continue", "when": "debugType == 'node'" }

9.5.6 Debug views sizes

We have fine-tuned the default sizes of Debug views. Also once the size is changed by the user, we preserve it across different VS Code sessions.

9.6 Node Debugging

9.6.1 Node2 transitioning

In this milestone, we’ve started to fold the two node debuggers (‘node’ and ‘node2’) into a single node debugging experience (behind the debug type ‘node’). The goal of this is to detect the supported debugging protocol(s) of the targeted Node.js runtime automatically and to select the best debugger implementation based on that protocol. We call the new protocol ‘inspector’ and the (now obsolete) v8-debugger protocol ‘legacy’.

Starting with this release, we recommend that you only use the ‘node’ debug type and we’ve deprecated the ‘node2’ type (‘node2’ is still available but its use in launch configurations will be flagged with a deprecation warning).

Since we still want to give you control over what debugger implementation to use, we’ve introduced a new attribute protocol with the following values:

  • auto: tries to automatically detect the protocol used by the targeted runtime. For configurations of request type launch and if no runtimeExecutable is specified, we try to determine the version by running Node.js from the PATH with an --version argument. If the version is >= 6.9, the new ‘inspector’ protocol is used. For configurations of request type ‘attach’, we try to connect with the new protocol and if that works, we use the ‘inspector’ protocol. We only switch to the new inspector protocol for versions >= 6.9 because of problems in earlier versions.
  • inspector: forces the node debugger to use the ‘inspector’ protocol based implementation (aka ‘node2’). This is supported by Node.js versions >= 6.3, but not (yet) by Electron.
  • legacy: forces the node debugger to use the ‘legacy’ protocol based implementation. This is supported by Node.js versions < v8.0).

In the future auto will be the default, however since the transition to the new node debugging experience hasn’t been finished yet (and we were not brave enough to enable it by default), we continue to use legacy for the time being.

But we would like to encourage you to use 'protocol': 'auto' in your launch configurations and provide feedback if you experience problems.

9.7 Task support

9.7.1 Key bindings per task

You can now bind a keyboard shortcut to any task you want.

Simply add a key binding like this:

{
    "key": "ctrl+h",
    "command": "workbench.action.tasks.runTask",
    "args": "tsc"
}

This binds ctrl+h to the task named tsc.

9.7.2 More work on Terminal Runner

As announced in the previous release, we are working on running tasks in the Integrated Terminal instead of the Output panel. In this release, we added support to compose tasks out of simpler tasks. If, for example, you have a workspace with a client and server folder and both contain a build script, you can now have one task that starts both build scripts in separate terminals.

The tasks.json file looks like this:

{
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "Client Build",
            "command": "gulp",
            "args": ["build"],
            "isShellCommand": true,
            "options": {
                "cwd": "${workspaceRoot}/client"
            }
        },
        {
            "taskName": "Server Build",
            "command": "gulp",
            "args": ["build"],
            "isShellCommand": true,
            "options": {
                "cwd": "${workspaceRoot}/server"
            }
        },
        {
            "taskName": "Build",
            "dependsOn": ["Client Build", "Server Build"]
        }
    ]
}

Please note the following things:

  • This support is preliminary and subject to change.
  • The terminal task runner can now also be enabled by using the "version": "2.0.0" property.

9.7.3 Facilitating automation with ${lineNumber}

As requested by the community, we added a new variable ${lineNumber} for tasks.json and launch.json. It resolves to the selected line in the currently opened file. This new variable facilitates automation (e.g. running tests) under cursor selection.

9.8 Extension Authoring

9.8.1 Contributable SCM providers

We made further progress in February on creating a pluggable Source Control feature set for VS Code. Namely, all Git features were ported over to a Git extension.

All VS Code Insiders will get this new interface and we’ll use the March milestone to tune and tweak the experience. You can try this out via the SCM: Enable Preview SCM command, which will replace the legacy Git functionality with the experimental one (run SCM: Disable Preview SCM to undo).

The window.showInformationMessage and similar API calls have been updated to allow the use of modal message dialogs.

Here’s an example using the modal parameter:

window.showInformationMessage('Do you want to continue?', { modal: true }, 'Yes', 'No');

9.8.3 Context specific visibility of Command Palette menu items

When registering commands in package.json, they will automatically be shown in the Command Palette (kb(workbench.action.showCommands)). To allow more control over command visibility, we have added the commandPalette menu item. It allows you to define a when condition to control if a command should be visible in the Command Palette or not.

The snippet below makes the ‘Hello World’ command only visible in the Command Palette when something is selected in the editor:

"commands": [{
    "command": "extension.sayHello",
    "title": "Hello World"
}],
"menus": {
    "commandPalette": [{
        "command": "extension.sayHello",
        "when": "editorHasSelection"
    }]
}

9.8.4 Language specific editor settings

In this release, we added support for following language specific editor settings:

editor.tabSize
editor.insertSpaces
editor.detectIndentation
editor.trimAutoWhitespace

Default language specific editor settings: Extension authors can now contribute default language specific editor settings using the newly introduced extension point configurationDefaults in package.json.

Following example contributes default editor settings for the markdown language.

contributes": {
    "configurationDefaults": {
        "[markdown]": {
            "editor.wordWrap": "on",
            "editor.quickSuggestions": false
        }
    }
}

9.8.5 Debug Adapter Protocol

A new optional attribute clientID has been added to the InitializeRequestArguments. With this addition, a debug adapter can identify the client (frontend). We maintain a list of client IDs here.

For obtaining more information about thrown exceptions, we’ve introduced a new ExceptionInfoRequest and a corresponding type ExceptionDetails.

9.9 Miscellaneous

9.9.1 Official signed repositories for Linux

For Debian-based distributions, we now ship both Stable and Insiders in a signed apt repository that is automatically installed when you install the .deb package. This enables automatic updates using the platform’s update mechanism.

apt repository

For Red Hat-based distributions, we ship Stable in a signed yum repository. You can install the repository by following these instructions.

9.9.2 Monitoring startup performance

Startup performance is important and we continuously try to improve it. Sometimes startup performance gets slower, mostly because of changes with unintended effects or because of changes in our dependencies. To ensure we see this early and to fix performance regressions, we have started to monitor the startup performance of a dedicated machine. We took a slightly outdated and dusty laptop and set it up as a build machine. Its ‘build result’ involves starting VS Code a couple of times and sending the startup timings to our telemetry stores. We also created a dashboard with visualizations of that data (PowerBI) and a slack bot (Azure Functions) that tells us once a day what the numbers are.

perf bot

9.10 Notable Changes

  • 1426: macOS: file events are not reported when using workspace path with different casing
  • 12000: Terminals created in the background by the API will not display/retain any output until the terminal panel is initialized
  • 15364: Make tabs smaller when workbench.editor.showTabCloseButton: false
  • 16820: Hot Exit: Opens the same file twice in two separate windows
  • 19625: API doesn’t update settings if there are trailing commas in settings.json.
  • 19526: Filter installed extensions.
  • 10610: When I hit a breakpoint VS Code opens a new readonly version of the file, breakpoints not shown in gutter.
  • 19840: IntelliSense freezes at random instances
  • 19993: Search perf regression in 1.9

These are the closed bugs and these are the closed feature requests for the 1.10 update.

9.11 Known Issues

9.12 Contributions to Extensions

Our team maintains or contributes to a number of VS Code extensions. Most notably:

We also continued the work on our PHP parser. We designed it to help extension authors provide better tooling support for PHP. To verify our design and to help the PHP community with concrete first steps, we started to adopt the parser in the PHP language server.

9.13 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:

  • darkred (@darkred): Move the ‘Release Notes’ from inside ‘eslint/README.md’ to a separate ‘eslint/CHANGELOG.md’ PR #205

Contributions to language-server-protocol:

Contributions to vscode-languageserver-node:

Contributions to vscode-languageserver-node-example:

Contributions to vscode-html-languageservice:

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

10 March 2017 (version 1.11)

Update 1.11.2: Adds the 1.11 translations and addresses these issues.

Update 1.11.1: Fixes these issues.

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


10.0.1 Troubleshooting

Some users are reporting issues with the new Git integration and the keyboard layout support.

If you like to go back to the previous behavior, you can apply the following workarounds:

  • Git integration - Run the SCM: Disable Preview SCM command.
  • Keyboard layout - Use the setting "keyboard.dispatch": "keyCode".

10.1 March Release Summary

Welcome to the March 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:

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

  • Editor - New Git SCM provider enabled by default, better file encoding detection, set the default language mode.
  • Workbench - Quickly navigate between and resize views, reveal editor if already open.
  • Languages - TypeScript 2.2.2, simplified TypeScript server log collection, Objective-C++ support.
  • Debugging - Column breakpoints improvements, additional exception information.
  • Node.js Debugging - Call stacks show async frames, access loaded scripts.
  • Tasks - Extensions can now provide custom tasks and problem matchers.
  • Extension Authoring - Debug extension improvements, increased extension size limit.

**Tip:** 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.

10.2 Workbench

10.2.1 Preview: Workbench theming

The first results of the effort on workbench theming are now visible. The built-in themes Abyss, Quiet Light, and Solarized Dark take advantage of new color theming capabilities.

Abyss theme with more colors

There are still several gaps and we have not finalized the new theme file format. For that reason, there’s no documentation and we ask theme authors to not use the new theme format yet.

However, if you want to play around with new colors, use the setting workbench.experimental.colorCustomizations to customize the currently selected theme.

color customization

10.2.2 Keyboard shortcuts editor

With this release, VS Code provides a rich and easy keyboard shortcuts editing experience using a new Keyboard Shortcuts editor. You can now find a command and change/remove/reset its key binding easily. Most importantly, you can see key bindings according to your keyboard layout, instead of mapping keys in the earlier json-based key bindings editor to your keyboard layout. The dialog to enter key bindings will assign the correct and desired key binding as per your keyboard layout.

Keyboard Shortcuts

NOTE: For more advanced customizations like editing when clause context of a key binding, you can open the keybindings.json file just like before and edit.

10.2.3 Improved keyboard layout support

On Windows and macOS, we now detect when the keyboard layout has been switched while VS Code is running and will update all keyboard shortcuts appropriately.

On Linux and macOS, we have made significant changes in how keyboard shortcuts are dispatched; we have switched to using the brand new KeyboardEvent.code. This new dispatching logic will result in changes in default keyboard shortcuts for non-US standard keyboard layouts. Unfortunately, due to the indeterminate nature of KeyboardEvent.keyCode on these platforms, we cannot be sure in each case the exact changed keybindings and present a list. In most cases, we expect the impact to be limited to the following built-in actions:

  • Toggle Integrated Terminal
  • Create New Integrated Terminal
  • Zoom in, Zoom out
  • Indent Line, Outdent Line
  • Fold, Unfold
  • Split Editor
  • Toggle Line Comment

You can read more in our wiki or in the plan item.

Note: If you experience issues with KeyboardEvent.code based dispatching on macOS or Linux, you can use the setting "keyboard.dispatch": "keyCode" to force VS Code to dispatch on KeyboardEvent.keyCode.

10.2.4 Text search improvements

Search is now powered by the excellent tool ripgrep, from Andrew Gallant (@BurntSushi), and searching should now be significantly faster. If you encounter an issue and need to revert to the previous search experience, you can set the option "search.useRipgrep": false.

Our ripgrep-based search can now respect .gitignore files as well. Enable it with the new Use Ignore Files button in the Search view, or by default with "search.useIgnoreFilesByDefault": true.

gitignore

The gear icon next to it is also new, and toggles whether search will ignore the patterns specified in the files.exclude and search.exclude settings.

10.2.5 Maximize and restore the panel size

We have added a maximize/restore button to the panel title area:

Panel

10.2.6 New setting to keep editor open even when file is deleted

There is a new setting workbench.editor.closeOnFileDelete that can be set to false to keep editors open even if the file was deleted on disk. Editors will indicate if the file was deleted on disk with their label.

Deleted File

Note: Files that get deleted via the Explorer will still cause the editor to close.

10.2.7 Join editors of two groups

A new command (workbench.action.joinTwoGroups) was added to join the editors of one group with the one to the left. This allows to quickly reduce the number of opened editor groups without losing any of the editors inside.

New commands have been added to navigate between the visible views of the application. For example, when focus is inside the first editor group, workbench.action.navigateLeft will bring you to the Side Bar. Similar, workbench.action.navigateDown would move focus to the panel.

10.2.9 Resize a view with keyboard

New commands are available to resize the currently focused view with the keyboard. Use workbench.action.increaseViewSize and workbench.action.decreaseViewSize to change the view size in increments.

10.2.10 New setting to reveal editor if opened

A new setting workbench.editor.revealIfOpen can be enabled to prevent opening the same file in another group if the file was already opened. One common scenario is the file picker (Quick Open): by default, it will open a file in the current active Editor Group. Changing this setting will prefer to open the file in any of the other groups in case the file is already opened there.

Note: There are still ways that the same editor will open in multiple groups, for example when you click the split editor action.

10.3 Editor

10.3.1 Drag and drop improvements

You can now copy selected text instead of moving it when you drag and drop. The experience is the same as you have on your platform. On macOS, press and hold the Option key while you drag and drop. Press the kbstyle(Ctrl) key on Windows and press the kbstyle(Alt) key on Linux.

When you drag and drop with or without copying the text, the style of the mouse pointer will change accordingly. You will see a + (plus) image when copying.

dnd

10.3.2 Git extension enabled

The new Git source control extension is now enabled by default. This Git integration goes through the same extension points as third-party SCM providers. We’re still working on the Git extension and if you’d like to go back to the previous version, you can run the SCM: Disable Preview SCM command to switch back.

You can quickly tell if the Git extension is enabled by looking at the Activity Bar icon. The new SCM provider integration will show a merge icon instead of the Git icon:

scm provider icon

10.3.3 Turn off occurrences highlight

There is a new option, editor.occurrencesHighlight that can be set to false to turn off highlighting of the selected word or word under cursor in cases where these highlights are computed by a rich language service.

10.3.4 Auto guess encoding of files

You can now let VS Code guess the encoding of a file automatically via the new files.autoGuessEncoding setting which is disabled by default. Once enabled, we will do an attempt at guessing the encoding from the file and use that information if there is a suitable encoding detected.

Note: there are cases where the encoding is detected wrongly or not at all. To have full control over the encoding in the workspace, use the files.encoding setting instead.

On top of that, if you select the encoding picker on a file to change its encoding, we will now present you the guessed encoding (if any) to the top of that list, making it very easy to pick the right encoding in case the file contents are not showing correctly and we can detect the encoding from the contents:

encoding

Note: The encoding is guessed, and can be wrong. There is no 100% accurate way to find the encoding from the contents of a file. The only exception is using a BOM (byte order mark) for UTF-8 or UTF-16 files.

10.3.5 More Fuzzy Matching

We have improved the filtering and scoring of suggestions. In addition to prefix and camel-case matching continuous substring matching is supported.

dnd

10.3.6 IntelliSense in comments

There is no more eager IntelliSense when typing in comments or strings! You can still request completions with kbstyle(Ctrl+Space) but quick suggestions, AKA “24x7 IntelliSense”, are disabled by default in comments and strings. To tune the suggestions behavior to your needs, we now allow more control over the editor.quickSuggestions setting:

"editor.quickSuggestions": {
    "comments": false, // <- no 24x7 IntelliSense in comments
    "strings": true, // but in strings and the other parts of source files
    "other": true,
}

10.3.7 Set the default language for new files

A new setting files.defaultLanguage can be used to set the language mode for new files that are untitled and not saved yet. This setting avoids having to pick the language each time you open a new file if you are often working on the same file type.

10.4 Integrated Terminal

The terminal links feature that was introduced last month got some more polish this version. The experience is now aligned with the editor, requiring kbstyle(Ctrl) or kbstyle(Cmd) to be held depending on your platform.

Terminal link hints

Also all links are now validated so only links that actually go somewhere will react to user action.

10.4.2 Improved start experience on Windows

Unlike on macOS and Linux with their SHELL environment variable, Windows doesn’t really have a reliable alternative. There is COMSPEC but unfortunately it always defaults to the 32-bit variant of Command Prompt and it’s seldom modified. To work around this, we’ve introduced a message when the terminal is first launched on Windows that allows users to select from a set of shells detected on the machine.

Terminal shell selector

10.4.3 Custom workspace shell settings

In VS Code v1.9, we disallowed workspace settings from configuring the terminal shell as it could have potentially been exploited maliciously. We are now re-allowing this but requiring an explicit user opt-in for each workspace before the settings will be picked up.

Terminal workspace settings warning

10.4.4 Warn when closing window with active terminal sessions

The new setting terminal.integrated.confirmOnExit has been added that presents a confirmation dialog when the window is closing with active terminal sessions. This is disabled by default.

10.4.5 Resizing horizontally no longer discards data

Thanks to an upstream PR from Lucian Buzzo, data is no longer discarded when resizing the terminal prompt horizontally.

10.5 Tasks

In this release, we opened up tasks for contributions from extensions. They can contribute problem patterns and problem matchers via the extension’s package.json file. These contributions work in both the output panel runner and in the new (not yet the default) terminal runner. Below an example to contribute a problem matcher for the gcc compiler in an extension:

{
  "contributes": {
    "problemMatchers": [
      {
          // the name of the problem matcher
          "name": "gcc",
          // The problem is owned by the cpp language service.
          "owner": "cpp",
          // The file name for reported problems is relative to the opened folder.
          "fileLocation": ["relative", "${workspaceRoot}"],
          // The actual pattern to match problems in the output.
          "pattern": {
              // The regular expression. Example to match: helloWorld.c:5:3: warning: implicit declaration of function ‘prinft’ [-Wimplicit-function-declaration]
              "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
              // The first match group matches the file name which is relative.
              "file": 1,
              // The second match group matches the line on which the problem occurred.
              "line": 2,
              // The third match group matches the column at which the problem occurred.
              "column": 3,
              // The fourth match group matches the problem's severity. Can be ignored. Then all problems are captured as errors.
              "severity": 4,
              // The fifth match group matches the message.
              "message": 5
          }
      }
    ]
  }
}

This problem matcher can now be used in a tasks.json via a name reference $gcc. An example looks like this:

{
    "version": "0.1.0",
    "command": "gcc",
    "args": ["-Wall", "helloWorld.c", "-o", "helloWorld"],
    "problemMatcher": "$gcc"
}

We also now allow extensions to contribute tasks to the Run Task Quick Pick list programmatically. This opens VS Code up for use cases where an extension wants to add support for a specific build system and wants to contribute corresponding tasks. An example is the npm extension that can now contribute scripts defined in the package.json as tasks to VS Code programmatically.

Please note the following limitations:

  • Contributed tasks can only be executed in the new terminal runner. To enable the terminal runner, add "version": "2.0.0" to your tasks.json file.
  • The task API is currently in proposed state.

For an example of how to use the API, please refer to VS Code’s gulp extension or the proposed API file

10.6 Languages

10.6.1 TypeScript 2.2.2

VS Code now ships with TypeScript 2.2.2. This release includes a number of important bug fixes and performance improvements. You can find a complete list of changes here.

10.6.2 Implementation CodeLens for TypeScript

We now include a CodeLens that shows the number of implementers of interfaces and abstract classes in TypeScript code.

TypeScript Implementations CodeLens

Clicking on the CodeLens will display a list of all implementations.

TypeScript Implementations CodeLens

This feature is disabled by default and requires TypeScript 2.2.1+. To enable it, add "typescript.implementationsCodeLens.enabled": true to your settings.

10.6.3 Simplified TypeScript server log collection

Added a new "typescript.tsserver.log" setting to simplify the collection of logs from the TypeScript server that powers VS Code’s TypeScript and JavaScript language support. These logs can be used to debug issues with JS and TS language support, and make it easier for users to provide these logs during issue investigations.

The new logging experience is supported with TypeScript 2.2.2+. Set "typescript.tsserver.log": "verbose" and reload VS Code to enable logging to a file. Use the "TypeScript: Open TS Server log" command to open the log file in the editor.

10.6.4 Improved support for Objective C++

VS Code now includes an objective-cpp language mode for working with Objective-C++. Previously, .mm files were treated as regular C++. This release also improves syntax coloring of Objective-C++ files.

10.7 Debugging

10.7.1 Debug Menu

We have added a top level debug menu with the most common debug commands:

Debug Menu

Note: There is a new command (Install Additional Debuggers…) to bring up the Extension view to search for debugger extensions.

10.7.2 Column Breakpoints Improvements

It is now possible to edit multiple breakpoints on a line directly from the glyph margin context menu. Apart from this, there were issues with multiple breakpoints on a line which are now fixed.

Editable Column Breakpoints

10.7.3 More detailed exception experience

The editor’s “Peek UI” has been enhanced to show additional information for thrown exceptions, For example, VS Code’s built-in Node.js debugging now shows the stack trace:

Exception Peek UI show Stack Trace

Since this feature requires some adoption effort by debugger extensions, do not expect to see additional exception information in other debugger extensions immediately.

10.8 Node Debugging

10.8.1 Transitioning to the “inspector” protocol

In the February milestone, we folded the two Node.js debuggers (‘node’ and ‘node2’) into a single Node.js debugging experience and introduced a new launch configuration attribute protocol to control which protocol to use (for details see the section in the February release notes.

In this milestone, we’ve changed the default value for protocol from legacy to auto. So if you don’t specify the protocol explicitly in your launch configuration, VS Code Node.js debugging will now try to detect the protocol used by the targeted runtime automatically. Since we do not want to switch users to the new “inspector” protocol too aggressively, we will use the new protocol only for 8.x versions of Node.js.

If you experience problems with this automatic protocol switching, you can get back to the old behavior by explicitly setting protocol to legacy.

10.8.2 Async call stacks

When debugging async JavaScript in Node.js or Chrome, we now show the async frames that led to the current call stack across async calls. This is currently only supported when debugging with the inspector protocol via "protocol": "inspector". It can be disabled by setting "showAsyncStacks": false in the launch config.

Example:

In this code snippet, fetchData is an async function that returns a Promise. Without async stacks, we can’t see the calls that happened before the Promise was resolved:

Async Frames in Call Stack

But with the async call stacks, we can see the full call stack that produced the async call:

Async Frames in Call Stack

10.8.3 Access Loaded Scripts

It is now possible to access the loaded scripts of a JavaScript runtime. This is useful if you need to set a breakpoint in a script that is not part of your workspace and therefore cannot be easily located and opened through normal VS Code file browsing. A typical scenario for this is a remote debugging session: you attach to a remote Node.js program and have no code available locally. See issue #20355 for other scenarios that drove this enhancement.

The Debug: Open Loaded Script action (kb(extension.node-debug.pickLoadedScript)) gives you access to loaded scripts while a debug session is active. In the Quick Pick, you can filter and select the script to open. The script is then loaded into a read-only editor where you can set breakpoints. These breakpoints are remembered across debug sessions but you only have access to the script content while a debug session is running.

Opening Loaded Script with Quick Pick

10.9 Extension Authoring

10.9.1 Source Control

A stable Source Control API was released this month which lets you create source control extensions integrated within VS Code. You can learn all about it in the Source Control in VS Code documentation page.

Some extension developers have already started adopting it:

10.9.2 API Improvements

  • The end of line sequence a document uses (crlf or lf) is now exposed via TextDocument#eol. Also, the TextEdit allows you to change EOL-sequence of a document.
  • We added these new completion item kinds: Constant, Struct, and EnumMember completing the existing Enum kind.

10.9.3 Debug Extensions

  • ExceptionInfoRequest now used by VS Code

If a debug adapter returns a non-falsy supportsExceptionInfoRequest capability, VS Code will now use the ExceptionInfoRequest to obtain additional information for the exception. Currently the attributes exceptionId, exception, breakMode, and details.stackTrace are displayed in VS Code’s exception Peek UI.

  • Server mode for debug adapters

VS Code always supported running debug adapters in server mode. However this was only officially supported for developing debug adapters, not for running them in production. With this release, we are starting to support the “server mode” as an official “run mode” for debug adapters. Please find the details for how to use this feature in the original feature request.

  • Changed semantics of StoppedEvent.reason

The semantics of the reason attribute of StoppedEvent has been changed slightly. Previously, it was specified that the reason attribute is shown in the UI (which has the consequence that the value needs to be translated to different languages). This makes it impossible for VS Code to interpret the reason attribute in a robust way. Starting with this release, VS Code uses the new attribute description when the “stopped” reason needs to be shown in the UI and uses the reason attribute to interpret the reason. If description is missing, VS Code falls back to the previous behavior.

  • New attribute presentationHint for StackFrame type

A new optional attribute presentationHint has been added to the StackFrame type which can be used to control how the client renders a stack frame in the UI.

  • Usage example for exception configuration API

The VS Code Mono debugger extension has been enhanced to use the recently introduced exceptionOptions attribute on the SetExceptionBreakpointsRequest for configuring exception catchpoints.

Configuring Exceptions

The implementation can serve as an example for how to use the debug adapter protocol (DAP) from an extension to add specific functionality that is not provided by the generic VS Code debugger UI.

10.9.4 Increase Extension Size Limit

In a collaboration with the Visual Studio Marketplace, we’ve increased the size limit of extensions in the Marketplace from 20MB to 100MB. You’ll need to update to vsce@1.20.0 to benefit from this.

10.10 Miscellaneous

10.10.1 Startup profiling for everyone

We have added a new command line option that allows you to profile the startup of VS Code. Run code like this code --prof-startup and it will create profiles for the main and renderer process. These profiles are stored in your home directory and we encourage you to share them with us. Often performance out in the wild is vastly different from our machines and getting more insights from you will help us improve VS Code.

10.10.2 Coming Soon: Support for community localization

VS Code currently ships with support for 9 languages: French, Italian, German, Spanish, Russian, Traditional and Simplified Chinese, Japanese, and Korean. In the March release, we started moving the current internal localization process to support the open translation platform called Transifex.

Once this work is done, we will be able to accept translations from the community directly instead of having to submit a bug and wait for us to localize the string(s).  Even more exciting though, this work enables VS Code to be localized by the community into additional languages such as Portuguese and Polish. In fact, we’re opening up translations into 8 additional languages: Czech, Dutch, Hungarian, Polish, Portuguese (Brazil and Portugal), Swedish, and Turkish.

If you are passionate about having a high quality VS Code in your native language, please come and help us!  Learn more at the Visual Studio Code Community Localization Project.

10.11 New Commands

Key Command Command id
kb(workbench.action.openGlobalSettings) Open User Settings openGlobalSettings
kb(workbench.action.revertAndCloseActiveEditor) Revert and Close Active Editor workbench.action.revertAndCloseActiveEditor
kb(workbench.action.joinTwoGroups) Join Editors of Two Groups workbench.action.joinTwoGroups
kb(workbench.action.navigateUp) Move to the View Part Above workbench.action.navigateUp
kb(workbench.action.navigateDown) Move to the View Part Below workbench.action.navigateDown
kb(workbench.action.navigateLeft) Move to the View Part to the Left workbench.action.navigateLeft
kb(workbench.action.navigateRight) Move to the View Part to the Right workbench.action.navigateRight
kb(workbench.action.increaseViewSize) Increase View Size workbench.action.increaseViewSize
kb(workbench.action.decreaseViewSize) Decrease View Size workbench.action.decreaseViewSize

10.12 Notable Changes

  • 12077: File does not reload in editor when quickly changed externally after making modifications
  • 13001: Keep scroll position stable when closing a tab
  • 13665: Improve VS Code when working with network drives
  • 19841: Node debug Step Over/Into hangs in 1.9
  • 20074: VS Code default language extensions override custom language extensions
  • 21948: Auto save no longer works
  • 22900: CPU usage even when idle (due to cursor rendering)
  • 22971: Run the terminal as a login shell by default on macOS
  • 22997: Execute Node.js application in external terminal throws error
  • 23494: Debugger does not work with electron v1.6.x

These are the closed bugs and these are the closed feature requests for the 1.11 update.

10.13 Contributions to Extensions

Our team maintains or contributes to a number of VS Code extensions. Most notably:

10.14 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-chrome-debug-core:

Contributions to language-server-protocol:

Contributions to vscode-languageserver-node:

Contributions to vscode-generator-code:

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

—
Order: 21
TOCTitle: April 2017
PageTitle: Visual Studio Code April 2017
MetaDescription: See what is new in the Visual Studio Code April 2017 Release (1.12)
MetaSocialImage: 1_12_release-highlights.png

11 April 2017 (version 1.12)

Update 1.12.2: Adds the 1.12 translations and addresses a handful of issues.

Update 1.12.1: Fixes an issue with .NET debugging.

Workaround for macOS flickering when running on high DPI external monitors.

Workaround for macOS blurry icons if certain environment variables are set.

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


Welcome to the April 2017 release of Visual Studio Code. For this iteration, we shifted from our usual focus on new features to improving our processes and code base. We reviewed and triaged all our open issues, fixed bugs, and reduced engineering debt. We still think you’ll find plenty to be excited about in this release.

During this milestone, we closed 2199 issues across all VS Code repositories. However, while we were busy closing issues, you were busy opening them. 1925 new issues, to be exact, and we decreased our total issue count by 274. By comparison, in March we closed 1719 issues while we gained 2221 issues, and our total issue count grew by 369. Overall, April looks pretty good.

And in case you are wondering, out of the 3775 issues that we currently track in github.com/Microsoft/vscode, 2368 are feature requests. We won’t run out of work anytime soon :-).

Having this out of the way, we promised the release notes would not be empty:

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

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

  • Workbench - macOS native Tabs and swipe gestures, terminal link line and column support.
  • Languages - TypeScript 2.3, apply Markdown snippets on selections.
  • Debugging - Context menu to edit watch expressions, better column breakpoints.
  • Extension Authoring - Progress UI for long running operations, new completion item types.

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.

11.1 Workbench

11.1.1 Workbench theming

The workbench theming work started in the March release has been continued at full steam. Most gaps are now closed and we are happy to declare the currently available state as ‘ready to use’ for theme authors.

Theming support for list & trees (in particular the File Explorer and suggestions widget), diff editor, activity bar, notifications, scrollbar, splitview, buttons and more.

activity bar theming

All built-in themes have been updated to take advantage of the new colors. You can find the full list of all colors in the Theme Color Reference.

kimbie dark

solarized-light

tomorrow blue

The new user settings workbench.colorCustomization replaces the setting workbench.experimental.colorCustomization and lets users change colors on top of the active theme. If you have already used the experimental settings, use the color id mapping table to map the ids to the new format.

The Yeoman generator has been updated to create themes using the new color theme format. In addition, a new command Developer: Generate Color Theme From Current Settings is available in the Command Palette to help you turn your custom colors to a theme that you can share on the Marketplace.

We’re also looking into ways to make theme creation easier in the vscode-theme-generator project on GitHub. The goal of the generator is to allow generation of good looking themes with as little effort as possible, hiding away the complexities of tweaking the individual workbench color keys and TextMate scopes.

With the vscode-theme-generator, you can create a theme that looks like this by defining only 6 colors:

Theme generator preview

11.1.2 Keyboard Shortcuts editor

Search in Keyboard Shortcuts editor is improved to support all possible terms for modifier keys in corresponding platforms.

  • meta, cmd, command, windows
  • ctrl, control
  • alt, option
  • shift

You can now also see the conflicts in the order of precedence.

Keyboard shortcuts editor

11.1.3 Source control

Since the SCM API was released, there has been good progress in source control extensions around the community. Here are some of the SCM extensions already published in the Marketplace:

We are very excited about the possibilities of this API and expect more extensions to come out in the near future!

11.1.4 Git

There has been a lot of progress improving the Git extension inside VS Code. This Git integration goes through the same extension points as third-party SCM providers.

Note: Starting in June, the legacy git integration will be completely removed. Until then, you can still revert back to it using the SCM: Enable Legacy Git command.

11.1.5 macOS: Sierra Tabs

With the help of the Electron update, we can bring back basic support for native macOS Sierra tabs for window management. You can enable them via the window.nativeTabs setting after a restart. Once enabled, depending on your OS settings, new tabs will open when you open new windows. Make sure to show the tab bar (View > Show Tab Bar) to access tabs.

native tabs

Note: Native tabs cannot be used with a custom title. When you enable native tabs, the title bar will change to native styling too.

11.1.6 macOS: Mouse swipe to navigate

We added a new setting workbench.editor.swipeToNavigate that allows you to navigate between editors using 3-finger-swipe gesture with the trackpad on macOS. Swiping left or right will navigate across recently used editors in any editor group. This is similar to the Go > Back and Go > Forward commands we already had but will skip navigation from occurring within documents.

Note: The same commands that swiping triggers can also be executed via key bindings from the new commands workbench.action.openPreviousRecentlyUsedEditor and workbench.action.openNextRecentlyUsedEditor.

Note: We currently only support 3-finger-swipe gesture. Make sure that your trackpad settings for swiping are configured like the following to make this work:

  • Swipe between pages: Scroll left or right with three fingers.
  • Swipe between full-screen apps: Swipe left or right with four fingers.

Links to files with line and column ranges are now supported.

Terminal line column links

11.2 Languages

11.2.1 TypeScript 2.3

VS Code now ships with TypeScript 2.3.2. This update brings some new language features and fixes a number of important bugs.

11.2.2 Type checking for JavaScript files

TypeScript 2.3 also brings type checking to plain JavaScript files. This is a great way to catch common programming mistakes and these type checks also enable some exciting quick fixes for JavaScript.

Using type checking and quick fixes in a JavaScript file

TypeScript can infer types in .js files same as in .ts files. When types cannot be inferred, they can be specified using JSDoc comments. You can read more about how TypeScript uses JSDocs for JavaScript type checking here.

Type checking of JavaScript is optional and opt-in. Existing JavaScript validation tools such as ESLint can be used alongside the new built-in type checking functionality.

You can get started with type checking a few different ways depending on your needs.

Per file

The easiest way to enable type checking in a JavaScript file is by adding // @ts-check to the top of a file.

// @ts-check
let easy = 'abc'
easy = 123 // Error: Type '123' is not assignable to type 'string'

Using // @ts-check is a good approach if you just want to try type checking in a few files but not yet enable it for an entire codebase.

Using a Setting

To enable type checking for all JavaScript files without changing any code, just add "javascript.implicitProjectConfig.checkJs": true to your workspace or user settings. This enables type checking for any JavaScript file that is not part of a jsconfig.json or tsconfig.json project.

You can opt individual files out of type checking with a // @ts-nocheck comment at the top of the file:

// @ts-nocheck
let easy = 'abc'
easy = 123 // No error

You can also disable individual errors in a JavaScript file using a // @ts-ignore comment on the line before the error:

let easy = 'abc'
// @ts-ignore
easy = 123 // No error

Using a JSConfig or TSConfig

To enable type checking for JavaScript files that are part of a jsconfig.json or tsconfig.json, simply add "checkJs": true to the project’s compiler options:

jsconfig.json:

{
    "compilerOptions": {
        "checkJs": true
    },
    "exclude": [
        "node_modules"
    ]
}

tsconfig.json:

{
    "compilerOptions": {
        "allowJs": true,
        "checkJs": true
    },
    "exclude": [
        "node_modules"
    ]
}

This enables type checking for all JavaScript files in the project. You can use // @ts-nocheck to disable type checking per file.

JavaScript type checking requires TypeScript 2.3. If you are unsure what version of TypeScript is currently active in your workspace, simply run the TypeScript: Select TypeScript Version command to check.

11.2.3 Change TypeScript versions without reloading VS Code

Changing the active version of TypeScript no longer requires VS Code to be reloaded.

11.2.4 Markdown Preview and Zoom

With the update of the Electron shell, we fixed the issue with clipping of Markdown previews and the in-product release notes when using Zoom.

11.2.5 Surround snippets for Markdown

You can now more quickly bold or italicize text in a Markdown document using snippets. Simply select some text and run the insert snippet command. The bold, italic, and quote snippets for Markdown have all been updated to operate on selected text.

You can also setup a key binding to use these snippets:

{
    "key": "cmd+k 8",
    "command": "editor.action.insertSnippet",
    "when": "resourceLangId == 'markdown'",
    "args": {
        "name": "Insert bold text"
    }
}

11.3 Editor

11.3.1 Dynamic IntelliSense sorting

The editor now re-sorts the completions list while you type. That ensures that the completions you need are always on top and easy to select.

Dynamic Sort

11.4 Tasks

11.4.1 Grunt task auto-detection

Grunt auto-detection has been implemented for the new terminal task runner. With the new terminal runner, tasks are now detected for both Grunt and Gulp if both corresponding files (Gruntfile.js, gulpfile.js) are present in a workspace.

In addition, the proposed task API has been polished. If you had already started to use it, you might encounter some minor breaking changes.

11.5 Debugging

11.5.1 Editing Watch expressions

It is now possible to edit Watch expressions using the context menu.

edit watch

11.6 Node Debugging

11.6.1 Just My Code improvements

Skipping files when stepping has been available for the inspector protocol of the Node.js debugger for three releases. With this release, it is now available for the legacy protocol as well. To control a file for skipping, use the context menu command Toggle skipping this file on a stack frame in the CALL STACK view.

toggle skip files

11.6.2 Column breakpoints improvements

Setting breakpoints on a particular column is now supported by the Debugger for Chrome extension, and by the inspector protocol of the Node.js debugger, when debugging (yet to be released) Node 8. A column breakpoint can be set using kb(editor.debug.action.toggleColumnBreakpoint) or via the context menu during a debug session.

column BPs

11.7 Extension Authoring

11.7.1 New APIs

We have added some new APIs:

  • More completion and symbol item kinds: Event, Operator, and TypeParameter.
  • You can now open a text document as a preview editor. This means its tab will be reused when opening another document. This can be done like so: vscode.window.showTextDocument(doc, { preview: true}).
  • We have added functions to show progress for a long running operation. For now, we have defined two locations for progress in the UI: the Source Control view and a window-global progress indication in the Status Bar.

Take a look at the following sample:

vscode.window.withProgress({
    location: vscode.ProgressLocation.Window,
    title: 'My long running operation'
}, async (progress) => {
    // Progress is shown while this function runs.
    // It can also return a promise which is then awaited
    progress.report({ message: 'Doing this' });
    await step1();

    progress.report({ message: 'Doing that' });
    await step2();
})

11.7.2 Node.js update (6.x to 7.x)

With the update of Electron to 1.6.6, the Node.js version that is used to run all extensions updated from 6.4.0 to 7.4.0. There are some breaking changes coming with this major update of Node.js, though in general the impact should be minor. Please refer to this overview for a complete list of breaking changes from Node.js 6 to 7.

One consequence of the Electron update is that promise rejections are now treated as uncaught exceptions by the Node.js runtime even if the reject is caught later. Since this behavior is annoying when debugging an extension, we’ve introduced a new exception option to control promise rejections independent from regular exceptions:

new promise rejection option

11.7.3 Debugger extensions

evaluateName attribute will become mandatory for Add to Watch and Copy Value actions

VS Code tries to implement the Add to Watch and Copy Value actions by using the data from the VARIABLES view and a JavaScript-biased heuristic for building expressions that can be used with the evaluate request.

Since this approach does not work for all languages, we’ve introduced the evaluateName attribute for variables some time ago. If the evaluateName attribute is available for a variable VS Code will use it ‘as is’ for the evaluate request. If evaluateName is missing, VS Code falls back to the old approach.

Since we plan to remove the fallback completely in the May release, debug adapters must support the evaluateName attribute if they want to have the Add to Watch and Copy Value actions available in the future.

New argument terminateDebuggee for disconnect request

An optional argument, terminateDebuggee, has been added to the disconnect request. If a debug adapter has opted into this feature with the supportTerminateDebuggee capability, a client can use this to control whether the debuggee should be terminated when the debugger is disconnected.

11.8 Miscellaneous

11.8.1 Electron update

In this release, we updated from Electron 1.4.x to 1.6.6. This brings a Chrome update from version 53 to 56 and Node.js from 6.4 to 7.4. Among other things, this update enabled us to bring back native macOS Sierra tabs for window management (behind a setting window.nativeTabs) as well as better crash reporting for the processes we spawn. This update also avoids some graphic glitches we have seen on macOS (background artifacts) as well as improved scaling of all UI elements when running with scaling enabled on Windows.

Unfortunately, we are also seeing some regressions with this update and we ask for your patience until we can move forward to a newer Electron version that fix these issues.

Specifically:

  • 24981: Backspace can not erase the last character during Chinese/Japanese IME conversion (macOS)
  • 24633: Unconfirmed text of CJK IME collapse to one character in Integrated Terminal
  • 24643: Webview Flickering on Resize
  • 24707: 1.6.2 update (<1.5) Completely breaks Dragon menu/submenu voice control (updated)
  • 25700: Windows: dropdown selector empty after reload of window

Note: If you are an extension author, please review the impact of this Electron update under the Extension Authoring section.

11.8.2 China downloads

We’ve improved the install and update experience for Chinese users, who have always reported slow download speeds when fetching releases of VS Code. We now publish and distribute our releases to network servers located within China so you should start getting much faster speeds in that territory. Some of our test scenarios witnessed a speedup of 300x ⚡️!

These improvements are available when downloading VS Code directly from our website as well as when receiving automatic updates.

11.9 New Commands

Key Command Command id
kb(workbench.action.openPreviousRecentlyUsedEditor) Open Previous Recently Used Editor workbench.action.openPreviousRecentlyUsedEditor
kb(workbench.action.openNextRecentlyUsedEditor) Open Next Recently Used Editor workbench.action.openNextRecentlyUsedEditor
kb(workbench.action.openGlobalKeybindingsFile) Open Keyboard Shortcuts File workbench.action.openGlobalKeybindingsFile

11.10 Notable Changes

  • 5745: Webview: apply window.zoomLevel too
  • 12473: macOS Sierra: background artifacts
  • 24482: New Uncaught Exception when starting an extension debugging session
  • 24979: Compound debug configurations not shown after first breakpoint is hit
  • 13306: stepping over breakpoint appears to resume execution fully, vs stepping
  • 24126: Quickly blinking cursor in terminal if you open and quit external app
  • 24302: Use ctrl key as the modifier to enable copy when drag and drop on Linux
  • 18351: Support navigation of problems by keyboard similar to search results.

These are the closed bugs and these are the closed feature requests for the 1.12 update.

11.11 Contributions to Extensions

Our team maintains or contributes to a number of VS Code extensions. Most notably:

11.12 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 language-server-protocol:

Contributions to vscode-languageserver-node:

Contributions to vscode-css-languageservice

11.13 Thank you to our localization contributors

We opened community localization this release and there was a lot of excitement from international users. We now have more than 100 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: Vincent Biret.
  • Italian: Piero Azi, Alessandro Burato, Giuliano Latini, Gianluca Bertelli.
  • German: Sascha Corti, Jens Suessmeyer, Christian Gräfe, Markus Weber.
  • Spanish: German Sak, Santiago Porras Rodríguez, José M. Aguilar, Alberto Poblacion.
  • Russian: Aleksey Nemiro, Kirill Moskvichev, Anton Afonin, Артем Мельниченко, Serge Rodionov, Andrei Pryymak.
  • Japanese: Yuichi Nukiyama, EbXpJ6bp.
  • Chinese (Simplified): Joel Yang, Ying Feng, YF.
  • Chinese (Traditional): Alan Tsai.

Although the languages below are not yet in VS Code, work is going on there as well. In the May iteration, we will review whether these languages meet the criteria for language integration into VS Code.

  • Portuguese (Brazil): Bruno Sonnino, Felipe Caputo, Rodrigo Crespi, Roberto Fonseca, Marcelo Fernandes, Roberto Nunes, Rodrigo Romano, Luan Moreno Medeiros Maciel, Ilton Sequeira, Douglas Eccker.
  • Dutch: Jeroen Hermans, Gerjan.
  • Polish: KarbonKitty, Lukasz Korowicki, Paweł Sołtysiak, Jakub Drozdek.
  • Swedish: Joakim Olsson.
  • Turkish: Adem Coşkuner, Serkan Inci, Sertac Ozercan.

11.14 Workarounds

11.14.1 macOS flickering

Some users are seeing VS Code flicker when running on high DPI external monitors #25934. The workaround is to set: "editor.disableTranslate3d": true in user settings (this produces a warning, but that is fine as VS Code still accepts the setting).

11.14.2 macOS blurry icons

This issue appears if certain environment variables are set when VS Code launches #24820. The workaround is to either launch VS Code from the macOS Dock or clear the LC_ALL environment variable (export LC_ALL=) before launching from the terminal. The Insiders build applies this workaround and clears LC_ALL.

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

—
Order: 22
TOCTitle: May 2017
PageTitle: Visual Studio Code May 2017
MetaDescription: See what is new in the Visual Studio Code May 2017 Release (1.13)
MetaSocialImage: 1_13_release-highlights.png

12 May 2017 (version 1.13)

Update 1.13.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 May 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, you can go to Updates on code.visualstudio.com.

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

  • Workbench - Filenames in symbol search, disable menu bar mnemonics.
  • Editor - Resizable Find widget, new folding control settings.
  • Languages - JSX/TSX component highlighting, Markdown headers in symbol search.
  • Debugging - Copy All from Debug Console, local/remote paths in launch configurations.
  • Tasks - Auto-detect and customize Gulp and Grunt tasks to run in VS Code.
  • Extension Authoring - Custom views in the Explorer, reference theme colors.

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.

12.1 Setting changes

12.1.1 Changed setting defaults

One thing you may notice right away in the May release is that we’ve changed the default value of several settings. Features such as minimap (outline view), icon themes, and indent guides have been off by default and we think they are so useful, we want to showcase them.

new setting defaults

Here are the new default settings:

Setting New Default Description
editor.minimap.enabled true Show file minimap (outline view) in the right gutter
workbench.iconTheme “vs-seti” Use vs-seti file icon theme
editor.renderIndentGuides true Display editor indentation guides
editor.dragAndDrop true Move editor selections with drag and drop
extensions.autoUpdate true Automatically update extensions
window.openFilesInNewWindow “off” Open files in the running VS Code instance

Of course, you can still configure VS Code to your preference with user or workspace settings (File > Preferences > Settings or keyboard shortcut kb(workbench.action.openGlobalSettings)).

12.1.2 Add multiple cursors with Ctrl / Cmd + Click

We have introduced a new setting, editor.multiCursorModifier, to change the modifier key for applying multiple cursors to Cmd+Click on macOS and Ctrl+Click on Windows and Linux. This lets users coming from other editors such as Sublime Text or Atom continue to use the keyboard modifier they are familiar with.

The setting can be set to:

  • ctrlCmd - Maps to Ctrl on Windows and Cmd on macOS.
  • alt - The existing default Alt.

There’s also a new menu item Use Ctrl+Click for Multi-Cursor in the Selection menu to quickly toggle this setting.

The Go To Definition and Open Link gestures will also respect this setting and adapt such that they do not conflict. For example, when the setting is ctrlCmd, multiple cursors can be added with Ctrl/Cmd+Click, and opening links or going to definition can be invoked with Alt+Click.

With fixing Issue #2106, it is now possible to also remove a cursor by using the same gesture on top of an existing selection.

12.2 Workbench

12.2.1 Filenames in symbol search results

You can use workspace symbol search (kb(workbench.action.showAllSymbols)) to quickly find symbols in your workspace. The list of results now includes the filename of each symbol:

symbol search includes filename

12.2.2 Disable menu bar mnemonics

A new setting window.enableMenuBarMnemonics was added to disable all mnemonics (hot keys) in the menu bar (on Windows and Linux). This frees up some Alt+ keyboard shortcuts to bind to other commands.

12.2.3 Install Additional SCM Providers

We have introduced a new command Install Additional SCM Providers… to make it easier to discover and install SCM providers from the VS Code Marketplace. The command is available under the Switch SCM Provider… command in the Source Control view and SCM: Switch SCM Provider in the Command Palette.

Install Additional SCM Providers

12.2.4 Go to Implementation and Go to Type Definition added to the Go menu

The Go menu now includes the Go to Implementation and Go to Type Definition commands:

New Go menu items

12.2.5 Preserving view state for resource editors

We are now preserving the view state for resource editors when you switch between them. This comes in handy when debugging internal modules since we now preserve the scroll position and all other view data for internal module editors. However, we always clear the view state when a user closes the editor.

12.2.6 High Contrast theme

We have improved the High Contrast theme to include more token colors and to use selection and Status Bar colors for clearer contrast.

High Contrast theme improvements

12.2.7 New theming colors

We received a lot of feedback for our workbench theming support and are happy to see more and more themes adopting the workbench colors! During this milestone, we added almost 50 new colors as well as did some tweaks to existing colors. These colors can be set by themes or directly by the user with the workbench.colorCustomizations setting.

You can review the new colors in the updated Theme Color Reference.

Below are the existing color behavior changes:

Key Description
panel.border Now overwrites the value of contrastBorder, allowing a more specific color if contrastBorder is set.
tab.border Now overwrites the value of contrastBorder, allowing a more specific color if contrastBorder is set.
editorGroup.border Now overwrites the value of contrastBorder, allowing a more specific color if contrastBorder is set.
list.* All list colors can now be set even in the presence of contrastBorder and contrastActiveBorder.

12.2.8 Multi-root workspaces

During this milestone, we made some significant steps towards supporting multi-root (multiple project folder) workspaces in VS Code. In case you are wondering why it is taking us a little bit longer to tackle this feature request, please read Daniel’s excellent explanation.

We focused on UX and sketched up how we could provide this feature with our current architecture without introducing too many new concepts. After sharing the designs with the engineering team, we ran 2 user studies to validate our assumptions. We encourage you to watch the recordings of these studies if you are interested and provide feedback:

With the UX work behind us, we feel that we can finally start implementing this feature request. Thanks for your patience!

12.3 Editor

12.3.1 Merge conflict coloring and actions

Inline merge conflicts are now colored and come with actions to accept either or both of the changes. Previously available as the popular Better Merge extension, this functionality is now built-in. Thanks to Phil Price (@pprice), the author of Better Merge, for the PR.

markdown symbols with header level

12.3.2 Suggestion list and documentation side by side

When IntelliSense autocomplete/suggestions are triggered, press kb(toggleSuggestionDetails) to view the documentation for the suggestion item in focus as before. The documentation will now expand to the side instead of being overlaid on the suggest widget, enabling you to read the documentation and navigate the list at the same time.

auto expanded docs in autocomplete

When the documentation fly-out is expanded, it will stay expanded (across VS Code windows, sessions and updates) every time autocomplete/suggestions is triggered, until you explicitly close it either using the close button or by pressing kb(editor.action.triggerSuggest) again.

For keyboard centric users who want to navigate up and down long documentation, press kb(toggleSuggestionFocus) to move the focus to the documentation fly-out such that it can now receive keyboard shortcuts for Page Up/Down actions.

For screen reader users, once the documentation fly-out is expanded, navigating the suggestion list will read out the label and documentation (if any) of the item in focus.

12.3.3 Emmet abbreviation expansion in suggestion list

Until now, the default behavior for expanding an Emmet expansion has been to use the kbstyle(Tab) key. There were two issues with this design:

  • Many unexpected Emmet expansions occurred when the user wanted to just add an indent.
  • On the other hand, items from the suggestion list got inserted when the user was expecting the Emmet abbreviation to be expanded.

Both of these issues can be now solved by having the expanded Emmet abbreviations show up in the suggestion list and freeing up the kbstyle(Tab) key for what it was meant to do, indenting.

Set emmet.useNewEmmet to true to start using this new feature. This feature is best used with the suggestion documentation fly-out expanded where you can preview the expanded abbreviation as you type. Note that kbstyle(Tab) key will no longer expand the abbreviation by default.

Emmet abbreviation expansion in autocomplete

If you have editor.quickSuggestions turned off, you can use one of the methods below to get Emmet expansion:

  • Manually trigger the suggestion by pressing kb(editor.action.triggerSuggest) and then choose the expansion from the suggestion list.
  • Run the command Emmet: Expand Abbreviation explicity from the Command Palette.
  • Bind your own keyboard shortcut to Emmet: Expand Abbreviation (command id editor.emmet.action.expandAbbreviation).

You will see two kinds of suggestions in HTML-like files:

  • The expansion for the abbreviation that has been typed (you can turn this off by setting emmet.showExpandedAbbreviation to false).
  • All possible abbreviations whose prefix is the text that has been typed (you can turn this off by setting emmet.showAbbreviationSuggestions to false). For example, a, a:link, a:mail, area are suggested when you type a. This is helpful for discovering Emmet abbreviations.

In CSS/LESS/SCSS files, you will only see the single abbreviation you have typed.

To implement this feature, we replaced the single monolithic Emmet library with smaller re-usable Emmet modules. In doing so, most of the Emmet commands were re-implemented. If you see any changes in the behavior of any Emmet commands, please create an issue. We hope to complete this work in the next milestone, after which the setting emmet.useNewEmmet will be deprecated and the new model will be made default.

12.3.4 Multi cursor snippets

You can now combine snippets and multiple cursors.

multi cursor snippets

In addition, you also now nest snippets, meaning you can add a placeholder of a snippet within another snippet and their placeholders will be merged.

12.3.5 Strict snippets

Snippets can have placeholders and variables. The snippet syntax is defined here where $1, $2... are tabstops and $varName1, $varName2... are variables. Note that they can only differ by what follows the $-sign, numbers are tabstops and words refer to variables. Prior to this milestone, VS Code was using an internal syntax for snippets. Textmate-style snippets were rewritten to the internal syntax and there was an unfortunate bug that caused variables to be turned into tabstops. This is what we have done to ensure a smooth transition:

  • When we encounter snippets that use variables we don’t know, we turn them into placeholders and warn the extension author (not the end user).
  • Also, we log a telemetry event so can make issues/PRs against extensions that are using this unfortunate construct.

In the future, you can expect us to continue to support these types of snippets for a little longer. Snippets fall into two categories; those that the user created and those that come from an extension. We will be strict on extension snippets while keeping support for user created snippets.

12.3.6 Find widget

You can now resize the Find widget horizontally. You can review the full text easily if it’s longer than the original width of the Find widget.

Resize Find widget

Also you can now scroll beyond the first line when the Find widget is visible and the Find widget won’t cover the matched results. We’ll automatically scroll the window a little bit to make sure the matched results are not covered by the Find widget when you are navigating between them.

Uncover matched results

We introduced two settings to help you customize the Find widget behaviors:

  • You can now set editor.find.seedSearchStringFromSelection to false if you don’t want to seed the search string in Find widget from current editor selection.
  • You can set editor.find.autoFindInSelection to true and then Find in Selection flag is turned on when multiple characters or lines of text are selected in the editor.

We also added a new command toggleFindInSelection (kb(toggleFindInSelection)) to toggle Find In Selection so you can keep your hands on the keyboard when switching all Find options.

12.3.7 Folding controls

The visibility of the folding controls next to the line numbers can now be configured by the setting editor.showFoldingControls:

  • mouseover - The existing behavior where controls for non-collapsed regions are hidden unless the mouse cursor is over the editor gutter.
  • always- Folding controls are always shown.

12.3.8 Letter spacing

Thanks to @hoovercj in PR #22979, there is a new editor setting, editor.letterSpacing, similar to the CSS letter-spacing property:

letter spacing

12.4 Integrated Terminal

12.4.1 Dragging files to the terminal to paste path

You can now drag files and folder from the File Explorer and files from your OS file manager to paste the path name into the terminal.

12.4.2 Unicode character width improvements

Unicode characters in the Integrated Terminal are now sized explicitly which means that applications like vtop which make extensive use of these characters should now render correctly.

Before:

Better unicode width before

After:

Better unicode width after

12.5 Tasks

12.5.1 Run tasks in the Integrated Terminal

You can now configure tasks so that they are executed inside the Integrated Terminal. By adding a runner property to the task.json file as shown below you enable the Integrated Terminal.

{
  "version": "0.1.0",
  "runner": "terminal",
  ...
}

If you want to switch back to the old runner, remove the property or set its value to "process".

12.5.2 Preview: Tasks version 2.0

You can opt into the new tasks version 2.0.0 but please note that this version is currently a preview and still under active development. We make it available in order to get early feedback.

To enable the tasks preview, set the version attribute to "2.0.0" :

{
  "version": "2.0.0"
}

With version 2.0.0 enabled, the tasks from different task runners like Gulp or Grunt are automatically detected and you can run them with the Run Task command. Tasks are currently auto detected from the task runners Gulp, Grunt, Jake, and from the scripts section in package.json files. We will provide an API so that you can contribute task detection for other task runners. This API has been further polished during this iteration, but we left in in the proposed state for this release (see vscode.proposed.d.ts).

The task selection dialog now shows you both tasks that you have configured in the task.json file and tasks that where automatically detected. For example, in a workspace with a gulp file defining a build and a watch task and a task.json file that defines a Deploy task, the task selection dialog looks as follows:

task selection

When the system detects a task (for example, a build task provided through a gulp file), it usually doesn’t know which problem matchers to associate with the task. You can customize a detected task inside the tasks.json file. To do so, press the gear icon to the right of a detected task. This will insert a section into the tasks.json file where you can customize the detected task.

The video below illustrates how to customize the gulp build task by adding the TypeScript problem matcher (named $tsc) to it and by renaming it to My Main Build.

task customize

12.6 Debugging

12.6.1 Improved stepping performance

Per a user recommendation, we’ve improved stepping performance by fetching parts of the call stack and the corresponding variables lazily, only if the user has not already requested the next “step” operation. With this change, VS Code will always fetch the top frame of the stack in order to be able to show the correct source for the current location. The rest of the stack will be updated only if the user has not continued stepping for 0.4 seconds.

This improves stepping performance considerably as you can see in the following screen recordings of the (rather large) Typescript compiler.

Old behavior - Always fetch full call stack:

step before

New behavior - Fetch rest of the call stack lazily:

step after

When an exception occurs, developers commonly follow through the exception stack trace to understand what caused it. We added a mechanism to detect links in the stack trace returned by the debug adapter. This allows you to jump to your source code straight from the exception UI. Moreover, it also improved existing link detection in a Debug Console, fixing several the user reported issues.

File Link Detection in Exception Peek UI

12.6.3 Recipes for nonstandard debugging scenarios

Setting up Node.js debugging can be challenging for some non-standard or complex scenarios. With this release, we’ve started to collect recipes for these scenarios in a new repository.

The initial recipes cover Debugging TypeScript in a Docker Container and Developing the MERN Starter in VS Code.

12.6.4 Copy All action in Debug Console

It is now possible to copy all the content from the Debug Console using the Copy All context menu action. More details about what motivated this change can be found here.

copy all

12.6.5 New setting debug.internalConsoleOptions

It is now possible to control the behavior of the Debug Console using the setting debug.internalConsoleOptions. Previously this setting was only available in launch.json, however by user request, it is now possible to also specify this in user and workspace settings. The setting in launch.json takes precedence if both are provided.

12.7 Node Debugging

12.7.1 Local/remote path mapping now supported for “launch” configurations

To facilitate remote debugging, VS Code already supports mapping JavaScript paths between a local VS Code project and a (remote) location by means of the localRoot and remoteRoot attributes. Because remote debugging typically involves “attaching” to a remote target, the localRoot and remoteRoot attributes were only available for launch configurations of request type "attach".

Recently we’ve opened up launch configurations of request type "launch" to launch arbitrary programs and scripts (and not just the local Node.js target to debug). With this, it becomes possible to launch a remote Node.js target (for example in a Docker container) and have the VS Code Node.js Debugger attach to it. This feature diminishes the difference between “launching” and “attaching” even further and it makes sense to support localRoot and remoteRoot attributes for launch configurations of request type "launch" as well (in addition to request type "attach").

You can find an example for this in the Debugging TypeScript in a Docker Container recipe.

12.8 Extensions

12.8.1 Enable / Disable commands

There are two new commands in the Extensions view context menu to help quickly manage your extensions:

  • Enable / Disable All Installed Extensions
  • Enable / Disable Auto Updating Extensions

Extensions actions

12.9 Languages

12.9.1 Syntax coloring for JSX/TSX components

In React JSX and TSX files, component classes are now colored differently than normal HTML elements:

new jsx coloring

12.9.2 Additional JSDoc tags in hover and suggestions

JSDoc tags such as @deprecated and @private are now displayed in hover and suggestions documentation.

JSDocs tags sections

12.9.3 Open TS Server Log reveals log folder

The TypeScript: Open TS Server Log command now reveals the TypeScript log directory on your operating system instead of trying to open the log file in VS Code. This is useful for collecting the additional Type Declaration (typings) installer log files generated alongside the main tsserver.log file.

12.9.4 Markdown preview preserves scroll position

The Markdown preview, along with other webview based views such as the release notes, will now preserve the scroll position when switching between editors. Previously, navigating away from the Markdown Preview and then returning to it caused the scroll position to be reset.

12.9.5 Warnings for missing Markdown preview styles

We now display a warning message if any of the stylesheets from markdown.styles used in the preview cannot be found.

12.9.6 Markdown symbol search includes heading levels

You can quickly jump to a heading in a Markdown file using Go to Symbol in File… (kb(workbench.action.gotoSymbol)). This list now includes the heading level of each symbol, which allows you to quickly filter results by heading level.

markdown symbols with header level

12.10 Extension Authoring

12.10.1 Custom views

There has been a popular request to customize VS Code to show custom data views, for example a Node Dependencies view. With this release, you can now write extensions to VS Code contributing such views. Currently custom views are shown only in Explorer. In future, we will support displaying them in other places too.

Custom view

Contributing a view is as simple as follows:

  • Contribute a view using the views extension point.
  • Register a data provider for the view using the TreeDataProvider API.
  • Contribute actions to the view using view/title and view/item/context locations in menus extension point.

You can refer to examples in our extension samples repository.

12.10.2 Debugger extensions

New enum value subtle for the presentationHint attribute of type StackFrame

A debug adapter can flag a stack frame with the presentation hint subtle in order to receive an alternative “subtle” rendering.

Extended type for TerminatedEvent.body.restart attribute

The type of the TerminatedEvent.body.restart attribute has been extended from boolean to any. This makes it possible to loop arbitrary data from one debug session to the next (restarted) debug session.

evaluateName attribute mandatory for Add to Watch and Copy Value actions

VS Code previously tried to implement the Add to Watch and Copy Value actions by using the data from the VARIABLES view and a JavaScript-biased heuristic for building expressions that can be used with the evaluate request.

Since this approach does not work for all languages, we’ve introduced the evaluateName attribute for variables some time ago. It is now mandatory for debug adapters to support the evaluateName attribute if they want that Add to Watch and Copy Value actions work properly.

12.10.3 Glob patterns for workspaceContains activation event

Thanks to @eamodio, with PR #24570, it is now possible to activate an extension when a folder is opened that contains at least one file that matches a glob pattern.

For example, an extension with the package.json:

{
  ...
  "activationEvents": [
    "workspaceContains:**/.editorconfig"
  ]
}

will be activated when a folder is opened and any of its sub-folders contains a file named .editorconfig.

12.10.4 Defining a language’s word pattern in the language configuration file

Thanks to @hoovercj, with PR #22478, it is possible to specify a language’s word pattern using wordPattern in the language configuration file. This used to be possible before only by invoking vscode.languages.setLanguageConfiguration(...).

12.10.5 Better control decorations in the editor

Thanks to @CoenraadS, with PR #25776, it is now possible to configure the behavior of decorations when typing/editing at their edges. This can be configured with the DecorationRenderOptions.rangeBehaviour field.

12.10.6 Reference theme colors from extensions

You can now use theme colors in decorators and for the Status Bar foreground. Using theme colors instead of actual color values is the preferred way as it lets themes and users customize the colors.

  var decorationType = vscode.window.createTextEditorDecorationType({
      before: {
          contentText: "\u26A0",
          color: new vscode.ThemeColor('editorWarning.foreground')
      }
  });

You will find the list of theme colors here.

12.11 Accessibility

12.11.1 Better NVDA support

Sometimes, when using arrow keys, some lines or characters would be repeated by NVDA (see Issue #26730). Thanks to James Teh, one of the co-founders of NV Access, we now understand the root cause (a timeout of 30ms, which we sometimes miss). James has a PR on NVDA where he is changing the default timeout to 100ms and making it configurable. Until a new NVDA version is shipped, thanks to Derek Riemer, there is an NVDA plugin that increases the timeout from 30ms to 200ms. We have also done some changes on our side to reduce the likelihood that we miss the 30ms timeout.

12.11.2 “Screen Reader Detected”

We are now leveraging Electron APIs to react and optimize VS Code when working with a screen reader. Whenever Electron identifies that a screen reader is attached, we will display a message in the Status Bar and:

  • Remove the Line Number and Column indicator from the Status Bar, as we have found updating these indicators causes a myriad of accessibility events that end up confusing screen readers.
  • Disable word wrapping, as when pressing arrow down for example, screen readers expect the cursor to move to the next line and not to a column to the right on the same line.
  • Mirror the current page of text in the editor synchronously to the <textarea> we use for input events.
  • Disable certain stylistic features to increase the likelihood that we make it within the 30ms accessibility event timeout. We typically do not spend more than ~4-5ms processing the arrow keys, but with these features disabled, the time spent is reduced to ~1-2ms. The rest of the time is spent by our platform in figuring out what happened and emitting the correct accessibility events.

Detecting screen readers is non-trivial, so, if you notice the “Screen Reader Detected” Status Bar message and do not have a screen reader attached, you can change the setting editor.accessibilitySupport from "auto" to "off".

12.12 Engineering

12.12.1 New crash report handling

We have improved the VS Code crash reporting. VS Code uses Electron’s built-in crash reporter to capture and analyze crash data to make VS Code and Electron itself better. If VS Code crashes, a dump is collected and sent to us, though you can always turn this off.

This worked well, but it was a time consuming task for us to analyze and understand a crash. Microsoft has a good crash reporting service called HockeyApp and we now have enabled HockeyApp for crash reporting. To enable it, we had to produce our own build of Electron because the built-in crash reporter sends data in a format HockeyApp does not understand. The changes are on top of Electron 1.6.6 where the crash reporter talks to the HockeyApp service.

If you build VS Code from source, you will continue to pull in the GitHub version of Electron. We will continue collaborating with the other Electron contributors to make the crash reporting service pluggable, so that anyone can easily use HockeyApp (or any other service).

12.12.2 Issue management automation

We have deployed a Probot instance to automate some of our issue management. You will see VSCodeBot add labels to issues on GitHub and sometimes close issues when they have gone stale. We are looking for feedback from the community and will add more automation as we go.

Adding an insiders label to an issue reported against an Insiders build:

VSCodeBot labels issues reported against Insiders build

Closing a stale needs more info issue after we haven’t heard back for more than week:

VSCodeBot closes stale needs more info issue

12.12.3 Automated Smoke Test

As part of this milestone, we automated the Smoke Test that we used to perform manually each release. All manual steps were automated with the use of the Spectron testing framework with detailed progress tracked in this issue.

The Smoke Test assists us in verifying whether all VS Code basic features are working before publishing a release. Automating the test enables us to save time on testing and put more resources and focus on the development of new features.

12.13 New Commands

Key Command Command id
kb(list.focusFirstChild) Select first child of currently selected item’s parent in tree/lists list.focusFirstChild
kb(list.focusLastChild) Select last child of currently selected item’s parent in tree/lists list.focusLastChild
kb(merge-conflict.next) Next Merge Conflict merge-conflict.next
kb(merge-conflict.previous) Previous Merge Conflict merge-conflict.previous
kb(merge-conflict.accept.selection) Accept Selection merge-conflict.accept.selection
kb(merge-conflict.accept.current) Accept Current merge-conflict.accept.current
kb(merge-conflict.accept.incoming) Accept Incoming merge-conflict.accept.incoming
kb(merge-conflict.accept.both) Accept Both merge-conflict.accept.both
kb(merge-conflict.accept.all-both) Accept All Both merge-conflict.accept.all-both
kb(merge-conflict.accept.all-current) Accept All Current merge-conflict.accept.all-current
kb(merge-conflict.accept.all-incoming) Accept All Incoming merge-conflict.accept.all-incoming
kb(merge-conflict.compare) Compare merge-conflict.compare

12.14 Contributions to Extensions

Our team maintains or contributes to a number of VS Code extensions. Most notably this month:

12.15 Notable Changes

  • 25789: Can’t split file when dragging from Explorer
  • 19644: Cursor does not go to the maximum line column when pressing “End” twice with word wrap enabled
  • 6661: Ctrl+D/Cmd+D merges adjacent selections.
  • 4271: Mac Insert Emoji Duplicates Text
  • 3623: Match whole word does not work for not latin characters (at least for cyrillic)
  • 17534: Search: not possible to remove individual search results in a file
  • 16580: Unable to write to settings should offer an action to open settings
  • 17609: Line wrapping problem in bash on ubuntu on windows
  • 23484: “Ctrl +click to follow link” hover appears only on the last link in the terminal
  • 25664: Terminal panel is not properly restored after restarting

12.16 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 language-server-protocol:

Contributions to vscode-languageserver-node:

Contributions to vscode-tslint:

Contributions to vscode-css-languageservice:

Contributions to vscode-chrome-debug-core:

Contributions to localization:

This is second month since we opened community localization in Transifex. We now have more 200 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: Vincent Biret, JP Gouigoux, Julien Brochet.
  • Italian: Aldo Donetti, Piero Azi, Luca Nardi, Giuseppe Pignataro.
  • German: Levin Rickert, Ingo Bleile, Carsten Kneip, Christian Gräfe, Markus Weber.
  • Spanish: Andy Gonzalez, Alberto Poblacion, José M. Aguilar, Juan Carlos Gonzalez Martin.
  • Russian: Al Fes, Aleksey Nemiro, Orrchy, Serge Rodionov.
  • Japanese: EbXpJ6bp, Yuichi Nukiyama, Yosuke Sano, Yuki Ueda, Takayoshi Tanaka, Tetsuya Fukuda, Takashi Kawasaki.
  • Korean: Ian Y. Choi.
  • Chinese (Simplified): Joel Yang, YF, Alan Tsai, 王韦煊, Jianfeng Fang, kui li.
  • Chinese (Traditional): Alan Liu, Alan Tsai, Duran Hsieh, Wei-Ting(DM), JJJ.

We would also like to congratulate and thank the Brazilian Portuguese community localization team! Due to their efforts, localization is now completed in Transifex and the translations have been integrated into the Insiders build for testing. Depending on validation progress, we hope to soon integrate the translations into the stable builds for Brazilian customers.

  • Portuguese (Brazil): Roberto Fonseca, Bruno Sonnino, Alessandro Fragnani, Douglas Eccker, Bruno Ochotorena, Rodrigo Crespi, Anderson Santos, Felipe Caputo, Marcelo Fernandes, Roberto Nunes, Rodrigo Romano, Luan Moreno Medeiros Maciel, Ilton Sequeira.

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

—
Order: 23
TOCTitle: June 2017
PageTitle: Visual Studio Code June 2017
MetaDescription: See what is new in the Visual Studio Code June 2017 Release (1.14)
MetaSocialImage: 1_14_release-highlights.png

13 June 2017 (version 1.14)

Update 1.14.1: The update addresses these issues.

  • The refactoring to convert a JavaScript ES5-style function class to an ES6 class is disabled.

Update 1.14.2: This update addresses these issues.

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


Welcome to the June 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, you can go to Updates on code.visualstudio.com.

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

  • Workbench - Restore loose files, quickly switch running windows (instances).
  • Languages - TypeScript 2.4, more relevant suggestions in JavaScript files.
  • Debugging - Simplifications for Node.js debug configurations.
  • Tasks - Auto-detect and customize npm scripts and TypeScript compiler to run in VS Code.
  • Extension Authoring - SVG rendering constraints, custom views visibility, new Debug API.

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.

13.1 Workbench

13.1.1 Lighter update experience

We’re working on toning down the update experience. The consensus was that the popup message to update VS Code was disruptive and we are experimenting with other UI affordances. This month, you’ll notice a little indicator in the bottom-left corner of the workbench when an update is available:

Update

Clicking on this indicator will let you apply the update as well as access other global actions (Command Palette, Settings).

Don’t worry about losing sight of this notification. macOS users will have the update automatically applied as soon as they restart VS Code, and Windows and Linux users will get the old pop-up message if they don’t accept the notification after a few days.

13.1.2 Command Palette improvements

We improved the Command Palette drop-down (kb(workbench.action.showCommands)) to make it more useful.

One popular request was to always restore the last typed input when reopening the Command Palette. Enable this behavior with the new setting workbench.commandPalette.preserveInput.

We also added a most recently used (MRU) list of commands that is persisted between restarts. The most recent commands executed will always show to the top. A new setting workbench.commandPalette.history allows you to control the number of entries to show (set it to 0 to disable this feature). With the MRU enabled, you do not need to enable workbench.commandPalette.preserveInput because the history will always have the last executed command selected by default when you open the Command Palette.

Commands History

A new command Clear Commands History was added to quickly dismiss all the entries from the commands history.

Finally, keyboard shortcuts in the drop-down are presented in the same visual form as in the Keyboard Shortcuts editor.

13.1.3 Restore empty workspaces

In VS Code, you can work with workspaces that have folders opened as well as empty workspaces. An empty workspace is not opened to a specific folder but can show files from disk. Up to now, we would never restore the UI state of empty workspaces and you would lose your carefully selected layout of opened files (even on window reload).

With this release, we will restore the UI state for empty workspaces in the same way we do for workspaces with opened folders.

Empty Workspace Restore

A new setting window.restoreWindows configures this behavior. The possible values are:

  • none - Never restore any workspaces
  • one - Restore the last active workspace (default)
  • folders - Only restore opened folders
  • all - Restore all workspaces.

With the new setting window.restoreWindows, we deprecated the previous setting window.reopenFolders and ask you to switch to the new setting. We will still support the old setting for a couple of releases.

13.1.4 Close unmodified files

A new command was introduced to close unmodified editors of the currently active editor group. This makes it easy to quickly dismiss tabs of editors that are not dirty (no unsaved changes). The action can be triggered not only via a keybinding (kb(workbench.action.closeUnmodifiedEditors)) but also from the context menus of the tabs (headers) as well as the OPEN EDITORS view in the Explorer.

Close Unmodified Editors

Thanks to Soney Mathew (@soneymathew) for providing the pull request for this feature!

13.1.5 Switch window improvements

In a previous release, we added a quick picker for switching between the opened windows (via the workbench.action.switchWindow command). In this release, we did some tweaks to make the experience better.

Switch Windows

You will now see icons for the currently active file or folder in the window, provided that you have enabled one of the File Icon themes.

In addition, a new command workbench.action.quickSwitchWindow was added to quickly switch between opened windows. Press and hold the modifier key to cycle through the list of windows and release all keys to open it.

As an example, to use this feature with the Ctrl+R keyboard shortcut, configure the following rule in the keybindings editor:

{
    "key": "ctrl+r",
    "command": "workbench.action.quickSwitchWindow"
},
{
    "key": "ctrl+r",
    "command": "workbench.action.quickOpenNavigateNext",
    "when": "inWindowsPicker"
}

Press Ctrl+R and leave the Ctrl key pressed. As long as you now press the R key, you can navigate through the list of windows. Release all keys to focus it.

Quick Switch Windows

13.1.6 New keybindings context per quick picker

Related to the improvements around the window picker, it is now easier and better to configure a picker with quick-pick functionality. Each time a picker opens, a specific keybinding context becomes active that you can use to assign keybindings to. For example, the window picker enables a context key inWindowsPicker when opened. Not only does it make quick navigate in pickers more powerful, it also fixes some annoying bugs. You can now bring up any quick picker, even if the quick picker is already showing (for example, opening the Quick Open file picker while the Command Palette is already open).

The following example demonstrates how to configure quick navigate keybindings to switch between the most recently opened folders:

As an example, to use this feature with the Ctr+J keyboard shortcut, configure the following rule in the keybindings editor:

{
    "key": "ctrl+j",
    "command": "workbench.action.quickOpenRecent"
},
{
    "key": "ctrl+j",
    "command": "workbench.action.quickOpenNavigateNext",
    "when": "inRecentFilesPicker"
}

Press Ctrl+J and leave the Ctrl key pressed. As long as you now press the J key, you can navigate through the list of recently opened folders and files. Release all keys to open it.

To make recommended extensions more visible, Extensions view now shows INSTALLED and RECOMMENDED extensions in two sections.

Extensions actions

13.1.8 Lists and quick pick leverage aria properties

Lists such as the suggestion widget, exception list and the Quick Open drop-down now set aria-setsize and aria-posinset. These lists are virtualized and so without these aria properties, screen readers could not correctly determine the number of entries.

13.2 Integrated Terminal

13.2.1 Selection re-implemented

The way selection works in the Integrated Terminal has been completely re-implemented by moving away from regular web selection to a model where it’s managed and rendered by the terminal itself. This fixes a lot of issues and here are the major call outs:

  • You can now select and copy text from more than one page of the terminal.
  • There is a new Select All command.
  • Copying wrapped lines will no longer add line breaks where they wrap.

Terminal selection changes

  • Double click word selection is improved, it will now select URLs and paths, rather than just fragments

Terminal double click word selection

  • Selection in tmux with mouse mode on should now work correctly

Terminal tmux improvements

13.2.2 Find in the terminal

The Integrated Terminal now has basic find functionality which can be triggered with kb(workbench.action.terminal.focusFindWidget).

Terminal find

If you want Ctrl+F to go to the shell instead of launching the Find widget on Linux and Windows, you will need to remove the keybinding like so:

{ "key": "ctrl+f", "command": "-workbench.action.terminal.focusFindWidget",
                      "when": "terminalFocus" },

13.2.3 Rename terminal sessions

Integrated Terminal sessions can now be renamed using the workbench.action.terminal.rename command. The new name will be displayed in the terminal selection drop-down.

13.3 Git

13.3.1 Pull from specific remote

Thanks to @BugraC, @matthewshirley, @Krzysztof-Cieslak, it’s now possible to pull changes from a specific branch in a remote repository with the Pull from… command.

13.3.2 Manage your .gitignore file

@BugraC also provided a change so that you can now add files to your .gitignore right from the context menu of the Source Control view or via the global Git: Add File to .gitignore command.

Tasks Global Menu

13.4 Tasks

To make tasks more convenient to use, we added a Tasks menu to the top-level menu bar:

Tasks Global Menu

The Tasks menu offers a new action Configure Default Build Task which when used with the 0.1.0 version of a tasks.json file, just opens the tasks.json file. The full power of the Tasks menu comes when using it with the 2.0.0 version of the tasks.json, which is now the default if no tasks.json file is present.

Many cool features come with the new task format:

  • The Run Task command now shows most recently used tasks first, then custom defined tasks, and last, auto-detected tasks.
  • Tasks are executed in the Integrated Terminal. This improves output encoding, brings full support for ANSI control sequences (for example, colors), and supports providing input to a task.
  • Task auto-detection for TypeScript, Gulp, Jake, Grunt and npm:

Task auto-detection

  • We are working with extension providers to add dotnet, Maven and others in the future.

  • As you can see from the image above, auto-detected tasks are prefixed with the type of task (‘npm:’, ‘gulp:’, ‘grunt:’, ‘tsc:’, or ‘jake:’). If you are referencing an auto-detected task in another file, for example as a preLaunchTask in launch.json, you will need to update that task reference with the prefix. Assuming you have the following launch.json and the “build” task comes from a gulp file,

{
    "version": "0.1.0",
    "configurations": [
        {
            ...
            "preLaunchTask": "build"
        }
    ]
}

you now need to change this to:

{
    "version": "0.1.0",
    "configurations": [
        {
            ...
            "preLaunchTask": "gulp: build"
        }
    ]
}
  • Guided problem matcher selection when executing a task without one:

Task problem matcher selection

  • Guided default build task selection. Simple run Configure Default Build Task from the global menu bar.
  • And of course you can still define your own custom tasks in the tasks.json file with full control over how they are executed in the terminal. For example, the tasks below executes a test script in the terminal and uses a new terminal for every test run:

json { "version": "2.0.0", "tasks": [ { "taskName": "Run tests", "type": "shell", "command": "./scripts/test.sh", "windows": { "command": ".\\scripts\\test.bat" }, "group": "test", "presentation": { "reveal": "always", "panel": "new" } } ] }

Consult the tasks documentation for a detailed list of new features and how to use them as well as instructions on how to best convert a 0.1.0 version tasks.json file to a 2.0.0.

Since we are now auto detecting all Gulp, Grunt, Jake and npm tasks available in a workspace you need to qualify the task name with the task runner when referencing it from a launch.json file. Assuming you have the following launch.json

{
    "version": "0.1.0",
    "configurations": [
        {
            ...
            "preLaunchTask": "build"
        }
    ]
}

and the "build" task comes from a gulp file you now need to change this to:

{
    "version": "0.1.0",
    "configurations": [
        {
            ...
            "preLaunchTask": "gulp: build"
        }
    ]
}

If you are unsure how the task name looks like execute Run Task… from the global Tasks menu and use the label presented in the list of tasks.

We also released the tasks API. If you want to provide task detection for your programming language, you should have a look at the API and at one of the VS Code task detection extensions like npm scripts autodetect.

13.5 Debugging

13.5.1 Recipe for Angular debugging

Setting up Node.js debugging can be challenging for some non-standard or complex scenarios. In May, we started to collect recipes for these scenarios in a recipe repository.

This release adds a new recipe by Tony Sneed (@tonysneed) for Chrome Debugging with Angular CLI.

13.5.2 Debug hover has scroll bar for long values

Thanks to a community pull request, a debug hover now displays long string values using a scroll bar.

13.6 Node Debugging

13.6.1 Windows executables are found even if no extension is specified

On Windows, it was previously necessary to include the correct file extension in the runtimeExecutable path, leading to complicated cross platform configurations:

    "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/nodemon",
    "windows": {
        "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/nodemon.cmd"
    }

With this release, it is no longer necessary to include the file extension which makes the path portable across all platforms:

    "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/nodemon"

13.6.2 Simplified setup for “Restart debug session”

VS Code Node.js debugging always supported restarting a debugging session automatically. This is useful if you use a file watching tool like nodemon to restart Node.js on file changes. Setting the launch configuration attribute restart to true makes the node debugger automatically try to re-attach to the Node.js runtime after Node.js has terminated. See the Node.js Debugging documentation for details.

In this release, we have simplified this feature by eliminating the need to set the debug flags and the port attribute explicitly. Depending on the protocol (“legacy” or “inspector”), VS Code will pass the correct --debug, --debug-brk, --inspect, --inspect-brk argument and a random port to the program specified as the runtimeExecutable and this port will be used for subsequent restarted sessions.

With this feature, the debug configuration for globally installed nodemon simplifies to:

{
    "name": "Launch server.js via nodemon",
    "type": "node",
    "request": "launch",
    "runtimeExecutable": "nodemon",
    "program": "${workspaceRoot}/server.js",
    "restart": true,
    "console": "integratedTerminal"
}

13.6.3 “Attach by process ID” support for all Node.js versions

VS Code Node.js debugging always supported debugging a Node.js process even if it was not launched in debug mode. For this, the debug configuration of type “attach” has to specify a processId attribute. With this release, we support this feature for all versions of Node.js (and not only for versions < 8.0 as before).

Different versions of Node.js support different debugging protocols. The VS Code Node.js debugger tries to determine automatically which protocol to use. If this is not possible, it defaults to the “legacy” protocol which is supported by all Node.js versions < 8.0. For details, see the Node.js Debugging documentation. Since the adoption of Node.js v8.x is steadily increasing, we are in the process of changing the default protocol for specific scenarios from “legacy” to “inspector”.

In this release, Node.js debugging will assume the “inspector” protocol whenever the runtimeExecutable attribute of a launch configuration is set. If you see your debug configurations failing, this change could be the reason. To fix this, you can either upgrade Node.js to version 8.x or you can explicitly force the use of the “legacy” protocol by adding "protocol": "legacy" to your launch configuration.

13.7 Languages

13.7.1 TypeScript 2.4

VS Code now ships with TypeScript 2.4.1. This release includes a number of new language features, bug fixes, and editor improvements. Some highlights include:

Dynamic Import Expressions

Support for the new ECMAScript import expression for lazily loading modules:

async function getZipFile(name: string, files: File[]): Promise<File> {
    const zipUtil = await import('./utils/create-zip-file');
    const zipContents = await zipUtil.getContentAsBlob(files);
    return new File(zipContents, name);
}

Parent method suggestions in subclasses

IntelliSense now displays interface and parent methods class methods in subclasses:

JavaScript method suggestions from parent class

This is helpful for overriding parent methods or implementing interfaces.

More relevant suggestions in JavaScript files

In VS Code 1.13, suggestions in JavaScript files include suggestions for types:

VS Code 1.13 JavaScript suggestions that include type suggestions

This meant that many suggestions that are generally not useful in JavaScript were shown, such as EvalErrorConstructor or EventInit.

VS Code 1.14 better filters JavaScript suggestions to only include those you typically care about while working in plain old JavaScript:

Improved VS Code 1.14 suggestions

13.7.2 Simpler building TypeScript using Tasks

You can now build TypeScript projects using kb(workbench.action.tasks.build) without having to configure a tasks.json file, all you need is a tsconfig.json file:

Building a TypeScript project using tasks

TypeScript will pick up all tsconfig.json projects in your workspace for building.

13.7.3 Formatting option for spaces after TypeScript type assertions

The new typescript.format.insertSpaceAfterTypeAssertion setting allows you to control the placement of spaces after a type assertion in TypeScript.

// Default formatting
<Foo>{ abc: 123, ... };

// With "typescript.format.insertSpaceAfterTypeAssertion":true
<Foo> { abc: 123, ... };

13.7.4 Refactoring support for JavaScript and TypeScript

Note: Due to performance issues in some scenarios, this refactoring is disabled in 1.14.1.

VS Code 1.14 includes initial support for refactoring JavaScript and TypeScript code. The first supported refactoring converts a JavaScript ES5-style function class to an ES6 class:

Converting an es5 class to an es6 class using refactorings

We plan to add additional refactorings in the future.

13.7.5 Control handling of line breaks in the Markdown preview

The new markdown.preview.breaks setting controls the rendering of line breaks in Markdown preview. By default, single line breaks in Markdown paragraphs are ignored. For example in the Markdown below:

# Hello world

This is the first sentence.
This is the second sentence.

This is the third sentence.

The Markdown preview would show:

Markdown preview normally ignores single line breaks

When "markdown.preview.breaks": true is set, all new lines in paragraphs are converted into <br> tags in the output HTML:

Markdown preview normally ignores single line breaks

13.8 Editor

13.8.1 Emmet abbreviation improvements

In the previous release, we introduced a new model for Emmet features which you can enable by setting emmet.useNewEmmet to true. Below are the improvements to this new model in the current release:

Multi cursor support in Emmet

Try out the multi cursor support for many of the Emmet commands after setting emmet.useNewEmmet to true and don’t forget to log issues if you find anything not working as expected.

Multi cursor in Emmet commands

Emmet customizations in the new Emmet model

The new Emmet model supports the following Emmet settings:

  • emmet.includeLanguages

    Add Emmet: Expand Abbreviation and Emmet: Wrap with Abbreviation support to the language of your choice by providing a mapping to an existing Emmet supported language. The new language goes on the left and the Emmet supported language on the right. Use language ids for both sides of the mapping.
    For example:

    "emmet.includeLanguages": {
        "javascript": "javascriptreact",
        "vue-html": "html",
        "plaintext": "jade"
    }
  • emmet.excludeLanguages

    If there is any language where you do not want to see Emmet expansions, add it in this setting which takes an array of language id strings.

  • emmet.syntaxProfiles

    See Emmet Customization of output profile to learn how you can customize the output of your HTML abbreviations.
    For example:

    "emmet.syntaxProfiles": {
        "html": {
            "attr_quotes": "single"
        },
        "jsx": {
            "self_closing_tag": true
        }
    }
  • emmet.variables

    Customize variables used by Emmet snippets.
    For example:

    "emmet.variables": {
        "lang": "de",
        "charset": "UTF-16"
    }
  • emmet.showExpandedAbbreviation

    Controls the Emmet suggestions that show up in the suggestion/completion list.

    • never - Never show Emmet abbreviations in the suggestion list for any language.
    • inMarkupAndStylesheetFilesOnly - Emmet abbreviations in the suggestion list for languages that are markup and stylesheet based (‘html’,‘pug’,‘slim’,‘haml’,‘xml’,‘xsl’,‘css’,‘scss’,‘sass’,‘less’,‘stylus’) (default).
    • always - Emmet abbreviations in the suggestion list in languages that are markup and stylesheet based as well as javascriptreact, typescriptreact and any other language that has been mapped in the new setting emmet.includeLanguages.

    Note: In the always mode, the new Emmet implementation is not context aware. For example, if you are editing a JavaScript React file, you will get Emmet suggestions not only when writing markup but also while writing JavaScript.

Enable language extensions to provide Emmet suggestions

To get around the issue of having Emmet suggestions show up in the non-markup and non-stylesheet sections of your source code, we have pulled out the Emmet completion provider to a module of its own. This enables language extensions to use the npm module vscode-emmet-helper and provide Emmet suggestions in the right context as they are more aware of the language structure than the Emmet extension.

13.8.2 Auto indent on type, move lines and paste

With this release, you can have auto indentation adjustment while typing, moving lines and pasting content in TypeScript, JavaScript, HTML, CSS, JSON or languages that have indentation rules. To enable this feature, set editor.autoIndent to true. The indentation rules are still under development so let us know if you run into any issues.

Indentation rules

We made some earlier improvements to the indentation rules in the 1.9 release. With this release, language extension authors can declare the indentation rules in a language-configuration.json file instead of registering them in the extension activation phase.

{
  "indentationRules": {
    "increaseIndentPattern": "^\\s*((begin|class|def|else|elsif|ensure|for|if|module|rescue|unless|until|when|while)|(.*\\sdo\\b))\\b[^\\{;]*$",
    "decreaseIndentPattern": "^\\s*([}\\]]([,)]?\\s*(#|$)|\\.[a-zA-Z_]\\w*\\b)|(end|rescue|ensure|else|elsif|when)\\b)"
  }
}

TypeScript, JavaScript, CSS, HTML and JSON have built-in indentation rules. We don’t ship indentation rules for other languages yet but if you use an extension which defines rules for another language, you will see the editor.autoIndent feature working.

Typing

For C-like languages, we already handle brackets nicely. We indent the next line when the user types an open bracket and adjust the indentation when the user types a matching close bracket. However we don’t have support for languages that use keywords to wrap blocks. With the new auto indent feature, it is now possible by creating indentation rules for that language.

auto-indent-on-type

Moving lines

When you move source code out of a nested block or move code from one block to another, the editor will adjust the indentation level automatically.

auto-indent-on-move-lines

Paste

Pasting is similar to moving lines, VS Code will adjust the indentation for you based on the lines before the pasted area.

auto-indent-on-paste

13.8.3 Minimap

The new "editor.minimap.showSlider" setting can be configured to "always" to always render the minimap (outline view) slider. There is now also a subtle indicator of the horizontal scroll position within the slider. The slider geometry computations received a lot of improvements too (see the Notable Changes section):

minimap-horizontal-slider

13.8.4 Diff editor review pane

We’ve added a review pane to the Diff editor, an experience especially designed for users of screen readers. Our diff editor is implemented as a composition of two editors, and each side is exposed as a regular code editor to screen readers. It is not clear (if possible) how we could automatically announce entering a diff region or the actual diff to a screen reader from the context of a code editor.

We therefore added F7 and Shift+F7 which will navigate through diffs and present them in a unified patch format. Lines can be navigated with arrow keys and pressing Enter will jump back in the diff editor and the selected line.

diff-review-pane

13.9 Extension Authoring

13.9.1 Constraints for rendering SVG images

Due to security concerns, we don’t want to render user provided SVG images within VS Code. We added constraints for extensions to make it safer for users when they browse the extension Marketplace within VS Code:

  • The icon provided in package.json may not be an SVG.
  • The badges provided in the package.json may not be SVGs unless they are from approved badge providers.
  • Image URLs in README.md and CHANGELOG.md need to resolve to https URLs.
  • Images in README.md and CHANGELOG.md may not be SVGs unless they are from approved badge providers.
  • Images in README.md and CHANGELOG.md may not use data URIs.

To help you adopt these constraints, VS Code shows linting errors in your extension’s package.json, README.md, and CHANGELOG.md files if they are not yet compliant. Also, the vsce publishing tool performs compliance checks and prevents you from uploading a new version of your extensions if there are problems.

13.9.2 Custom views

You can now control the visibility of a custom view by providing the when context value while defining it in views contribution section in package.json.

Example:

"views": {
    "explorer": [
        {
            "id": "extension.node-debug.loadedScriptsExplorer",
            "name": "Loaded Scripts",
            "when": "inDebugMode && debugType == 'node'"
        }
    ]
}

13.9.3 New Debug API

In this release, we’ve started to provide a Debug API for extensions.

The initial API covers the life-cycle of debug sessions:

  • createDebugSession for starting a debug session based on an in-memory launch configuration.
  • An onDidTerminateDebugSession event which indicates that a debug session has terminated.

Note: Currently this API is proposed, so in order to use it you must opt into it by adding a "enableProposedApi": true to package.json and you’ll have to copy the vscode.proposed.d.ts into your extension project. Also be aware that you cannot publish an extension to the Marketplace that uses the enableProposedApi attribute.

13.9.4 New Task API

If you want to provide task detection for your programming language, you can now use the official task API. Have a look at the API and at one of the VS Code task detection extensions like npm scripts autodetect.

13.9.5 Debug Adapter Protocol

New capability supportsDelayedStackTraceLoading

In the May release, we improved stepping performance by fetching parts of the call stack and the corresponding variables lazily. Later we learned that not all debug extensions were prepared to return the stack in chunks which could result in a duplicated top stack frame. We weren’t able to fix this problem in a robust way, so we decided that debug adapters should opt-in to the delayed loading of stack frames explicitly and a new capability supportsDelayedStackTraceLoading was introduced in the debug protocol. So if the lazy loading of stack frames was working fine in your debug extension and if you know that your debug adapter already supports both the startFrame and the levels attribute of the stackTrace request, you should return true for the supportsDelayedStackTraceLoading capability. This ensures that you’ll continue to see the improved stepping performance delivered in the June release.

New optional attribute includeAll for type StackFrameFormat

With this new option, the StackTraceRequest can be parameterized to include all stack frames, including those the debug adapter might otherwise hide.

13.10 Engineering

13.10.1 Windows 64 bit Insiders

Visual Studio Code 64-bit builds are now available on Windows for the Insiders build. They come in the usual Installer format as well as a ZIP archive. Make sure to uninstall the 32-bit version before you install the 64-bit one.

You should expect 64-bit builds of our Stable version next month.

13.10.2 Issue management automation

The Probot we deployed to assist in our issue management now uses a machine learning algorithm to guess the feature area of new issues. When the algorithm estimates a sufficiently high probability of being correct, the bot adds the area label and (in some cases) directly assigns the issue to a developer on the team:

VSCodeBot labels an new issue with the emmet label

For a few days after a new release, the bot labels new issues filed for that release with the new release label. This helps us quickly spot regressions introduced in the release. We remove the label after a few days:

VSCodeBot labels an new issue with the new release label

We are looking for feedback from the community and plan to add more automation.

13.10.3 Monaco Editor

We published a new version of the Monaco Editor, bringing it up to date with VS Code and making numerous accessibility improvements.

13.11 Preview: Multi Root Workspaces

We have been busy this milestone on the development of “Multi-Root Workspaces” in VS Code (refer to our previous release notes for the design decisions we made last sprint). The outcome of this work is what we call a “Minimum Viable Product” (MVP) to enable testing on multiple root folder workspaces. The features outlined below are currently only available from our Insiders build and not Stable. More work is needed before we can make this feature available for all users. To try it out, grab our Insiders build from https://code.visualstudio.com/insiders.

13.11.1 File Explorer

The File Explorer can now show multiple root folders in one tree. You can easily add root folders from the File menu or context menu:

Add Root Folder

Once a root folder is added, the Explorer will show the new folder as root in the files tree. You can right click on any of the root folders to add more root folders or to remove it.

Remove Root Folder

The File Explorer should work and behave as before. You can move files between root folders and use any of the typical file operation actions provided in the context menu and the Explorer view. Settings like files.exclude are supported for each root folder if configured and across all folders if configured as global user setting.

Full text search and the Quick Open file picker take the additional root folders into account. When searching, results from all of the root folders will show up in the search results view:

Multi Root Search

To distinguish results with the same file name across root folders, the name of the root folder is used as a prefix to the relative path in the results list. Settings like search.exclude are supported for each root folder if configured and across all folders if configured as global user setting.

Multi Root Quick Open

13.11.3 Settings

With multiple root folders in one workspace, it is possible to have a .vscode folder in each root folder defining the settings that should apply for that folder. We classified settings into Workspace and Folder scoped to determine which setting can be applied at Workspace and Folder level.

A subset of settings is supported at a Folder level in this environment, specifically:

  • editor.*
  • files.exclude
  • files.trimTrailingWhitespace
  • files.insertFinalNewLine
  • files.encoding
  • files.autoGuessEncoding
  • files.watcherExclude
  • search.exclude

Other settings are currently not supported on a per-folder basis and we will add more to the above list in the future.

Refer to the issue to get more information about how settings are applied in a multi-root workspace.

13.11.4 Proposed multi-root API

Having multiple folders open in the editor requires a more powerful API. From when only a single root was supported, there is the rootPath API and for compatibility that will remain. We have a new and more powerful API in the pipeline. The current proposed API is shown below and enables you to inspect all workspace folders and sends an event when those change. It also gives you access to the new configuration model.

export namespace workspace {
    /**
    * List of workspace folders or `undefined` when no folder is open. The *first*
    * element in the array is equal to the [`rootPath`](#workspace.rootPath)
    */
    export let workspaceFolders: Uri[] | undefined
    /**
     * An event that is emitted when a workspace folder is added or removed.
     */
    export const onDidChangeWorkspaceFolders: Event<WorkspaceFoldersChangeEvent>;
    /**
    * Get a configuration object.
    *
    * @param section A dot-separated identifier.
    * @param resource A resource for which configuration is asked
    * @return The full workspace configuration or a subset.
    */
    export function getConfiguration2(section?: string, resource?: Uri): WorkspaceConfiguration2;
}

export interface WorkspaceFoldersChangeEvent {
    readonly addedFolders: Uri[];
    readonly removedFolders: Uri[];
}

export interface WorkspaceConfiguration2 extends WorkspaceConfiguration {

    /**
    * Retrieve all information about a configuration setting. A configuration value
    * often consists of a *default* value, a global or installation-wide value,
    * a workspace-specific value and a folder-specific value.
    *
    * The *effective* value (returned by [`get`](#WorkspaceConfiguration.get))
    * is computed like this: `defaultValue` overwritten by `globalValue`,
    * `globalValue` overwritten by `workspaceValue`. `workspaceValue` overwritten by `folderValue`.
    *
    * *Note:* The configuration name must denote a leaf in the configuration tree
    * (`editor.fontSize` vs `editor`) otherwise no result is returned.
    *
    * @param section Configuration name, supports _dotted_ names.
    * @return Information about a configuration setting or `undefined`.
    */
    inspect<T>(section: string): { key: string; defaultValue?: T; globalValue?: T; workspaceValue?: T, folderValue?: T } | undefined;

}

Note: The API is still proposed and you will need to enable it per extension. In the package.json file of your extension, add the following line:

"enableProposedApi": true

Also, copy the vscode.proposed.d.ts file from our repository to your project. Including this file in your project enables type-checking and IntelliSense.

As the API is in the proposed state, it is still being refined and breaking changes are likely to happen. For that reason, we don’t support publishing extensions that use proposed APIs. However we do want extension writers, the clients of the extension API, to help us define how the final API should look and what it should support. Don’t be shy with feedback!

13.11.5 Upcoming features

There is still a lot of work ahead of us to make the multi-root experience great.

These areas will get special attention in the next milestone:

  • Source Control UI for multiple root folders
  • Task and Debug support
  • Rich languages support across root folders

13.12 New Commands

Key Command Command id
kb(workbench.action.closeUnmodifiedEditors) Close unmodified editors of the currently active editor group workbench.action.closeUnmodifiedEditors
kb(workbench.action.quickSwitchWindow) Quickly switch between opened windows (instances) workbench.action.quickSwitchWindow
kb(workbench.action.quickOpenRecent) Quickly switch between recently opened folders and files workbench.action.quickOpenRecent
kb(workbench.action.terminal.focusFindWidget) Integrated Terminal Find workbench.action.terminal.focusFindWidget
kb(workbench.action.terminal.selectAll) Integrated Terminal Select All workbench.action.terminal.selectAll
kb(workbench.action.terminal.rename) Integrated Terminal Rename workbench.action.terminal.rename
kb(editor.action.diffReview.next) Diff Editor Next Change editor.action.diffReview.next
kb(editor.action.diffReview.prev) Diff Editor Previous Change editor.action.diffReview.prev

13.13 Notable Changes

  • Now using will-change:transform instead of transform:translate3d(...) to hint editor browser layers. The “hidden” editor option editor.disableTranslate3d is replaced by editor.disableLayerHinting. See monaco-editor#426.
  • Replaced a bad usage of Array.splice in a loop, which makes large pastes significantly faster. See monaco-editor#351.
  • Reimplemented the scrollbar’s slider geometry computations, to take into account artificial slider size inflation at an earlier stage, which results in correct mouse control in large files. See 6710.
  • Reimplemented the minimap’s slider geometry in a similar spirit: 21346, 29326, 28944.
  • Found (with help from @fj128) and implemented a workaround for thin lines rendering when the CSS <-> screen pixel ratio is not an integer: 9634, 28542.

These are the closed bugs and these are the closed feature requests for the 1.14 update.

13.14 Contributions to Extensions

GitHub view showing issues and PRs

  • Git Lens: We added a stash explorer (Pull requests: #94, #102) to Git Lens, which allows you to see the content change of local stashes in VS Code Diff Editor.

  • VSTS Build Status: We added the ability to group several build definitions into a single build Status Bar indicator (pull request #12).

13.15 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-node-debug2:

Contributions to vscode-languageserver-node:

Contributions to vscode-recipes:

Contributions to vscode-extension-vscode:

Contributions to localization:

This is the third month since we opened community localization in Transifex. We now have more 270 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, Julien Brochet, JP Gouigoux.
  • Italian: Aldo Donetti, Steve Roger.
  • German: Jonas Thelemann, Levin Rickert, Christian Gräfe.
  • Spanish: Raúl Rama, Alberto Poblacion, José M. Aguilar, Andy Gonzalez.
  • Russian: sberbanker, Nikita Gryzlov, Friedrich von Never.
  • Japanese: Yuichi Nukiyama, EbXpJ6bp, Yosuke Sano, Yuki Ueda, tempura.sukiyaki.
  • Korean: Ian Y. Choi.
  • Chinese (Simplified): Joel Yang, 陈嘉恺, 王韦煊, Zijian Zhou, lychichem, YF.
  • Chinese (Traditional): Duran Hsieh, jasperjn, Alan Liu, balduran, Wei-Ting(DM), Will 保哥, Alan Tsai, Terry Sheng.

Following on the success of the Brazilian Portuguese translations last month, Hungarian and Turkish started this month. Congratulations and thanks to the Hungarian, Turkish, and Brazilian Portuguese community localization teams! Special thanks to Tar Dániel and Adem Coşkuner who localized the majority of the 3500 strings of their language. Due to the efforts of community members, localization is now completed in Transifex and the translations have been integrated into the Insiders build for testing. Depending on validation progress, we hope to soon integrate the translations into the stable builds.

  • Portuguese (Brazil): Bruno Sonnino, Roberto Fonseca, Douglas Eccker, Miguel de Mousa, Fabio Oliveira.
  • Hungarian: Tar Dániel, Milán Boleradszki, Béla Kovács.
  • Turkish: Adem Coşkuner, Ata Binen, Meriç Bağlayan, Mehmet Kut, Sertac Ozercan, Serkan Inci, Ramis Eren.

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

—
Order: 24
TOCTitle: July 2017
PageTitle: Visual Studio Code July 2017
MetaDescription: See what is new in the Visual Studio Code July 2017 Release (1.15)
MetaSocialImage: 1_15_release-highlights.png

14 July 2017 (version 1.15)

Update 1.15.1: The update addresses these issues.


Welcome to the July 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, you can go to Updates on code.visualstudio.com.

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

  • Editor - Predefined snippet choices, improved auto-indenting and diff editor.
  • Workbench - Customizable Explorer sort order and view layout, prefilled Quick Open actions.
  • Integrated Terminal - Improved switching, delete word keyboard shortcuts.
  • Tasks - Less and Sass compiler output parsing, new Status Bar display.
  • Extension Authoring - Multi-root support for debugging and settings, new Markdown Preview API.

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.

14.1 Editor

14.1.1 Large file support

Large files are always a great way to stress-test an editor. We currently use a line based representation of the text buffer, which has some serious advantages, but also disadvantages, especially in terms of memory consumption (for example, a file with very many short lines).

Any file that is over 30MB or over 300K lines will now be considered a large file and will be handled specially in some circumstances. By disabling certain features for large files, for example tokenization, line guides, and wrapping or folding, we were able to optimize memory usage, in some cases, by as much as 50%. Additionally, large files will never travel to our web worker, which computes diff information, link detection, or word based completions. This helps in reducing the memory pressure on the operating system.

Some of the optimizations will impact all files, although the effects should not be noticeable for small files. We decided to remove the hard-coded file size limit of 50MB on 64-bit installations and enforce a 300MB file size limit on 32-bit installations. Refer to #30180 for more information about the different optimizations.

14.1.2 Color Picker

We’ve introduced a color picker for color customizations in this release. It supports configuration of hue, saturation and opacity for the color that is picked up from the editor. It also provides the ability to trigger between different color modes by clicking on the color string at the top of the picker. The picker appears on a hover when you are over the color definition in a document.

Color Picker

For the preview, we enabled it for CSS, Sass and LESS files, supporting RGBA, HSLA and Hex color modes. We plan to extend the picker with more functionality as well as to enable extension authors to contribute their own color modes together with color definitions for their languages in future releases.

14.1.3 Auto indentation

In this milestone, we’ve turned on auto-indenting by default ("editor.autoIndent": true). If the language you are working with has proper indentation rules (for example, TypeScript, JSON, CSS), the indentation will be adjusted when you type, move lines and paste blocks of code.

14.1.4 Emmet 2.0

Two releases ago, we introduced a new Emmet implementation (“Emmet 2.0”). During it’s preview, users could opt-in and try new features such as showing Emmet abbreviations in the suggestion/auto-completion list and multi-cursor support for most of the Emmet actions. In this release, Emmet 2.0 and these features are enabled by default.

Now that Emmet abbreviations are displayed in the suggestion/auto-completion list, VS Code no longer triggers Emmet abbreviations with the kbstyle(Tab) key by default. This solves 2 major issues:

  • Unexpected Emmet expansions occurring when the user wanted to just add an indent using the kbstyle(Tab) key.
  • Items from the suggestion list getting inserted when the user actually wanted to expand an Emmet abbreviation.

You can still bind any keyboard shortcut (other than kbstyle(Tab) key) to the editor.emmet.action.expandAbbreviation command or use Emmet: Expand Abbreviation from the Command Palette.

Note: To continue to expand Emmet abbreviations and snippets using the kbstyle(Tab) key, set emmet.triggerExpansionOnTab to true.

14.1.4.1 Custom Emmet Snippets

If you use custom Emmet snippets, you will have to modify them slightly to make them work in the new Emmet.

  • HTML: Custom Emmet snippets in HTML should be a valid abbreviation. For example: use ul>li instead of <ul><li></li></ul>.
  • CSS: Name the custom Emmet snippets in CSS such that they only contain letters from the snippet value in the order that they appear in the latter, so that the fuzzy matching algorithm of the suggestion list can make the right match. For example, don’t use bc or darkc as the name for color: black. Use cb or cob instead.

Read more about the new Emmet in Emmet 2.0 blog post.

14.1.5 Support for snippet choices

With snippet choices, a placeholder can be prefilled with a set of values. The syntax is ${<number>|option_1,...,option_n|}.

Below is a working sample specifying a fixed set of color choices:

"color": {
  "prefix": "color",
  "body": "> Pick your favorite color ${1|red,green,blue,pink|}.\n< He likes $1."
}

snippet choices

Last but not least, when inserting snippets via IntelliSense a preview is now shown.

14.1.6 Improved diff editor results

In this release, we made some changes to our diff algorithm to adjust the differences (which are found with the help of a Longest-Common-Substring algorithm) in such a way that they are more pleasing to the human eye.

In some cases, this means we will be more aligned with the output of git diff (which also incorporates some of these heuristics), but in other cases (like when only trim whitespace has changed), our result will no longer contain the LCS, so it will be different than git diff, but in our opinion it will also be more pleasing.

14.2 Workbench

14.2.1 User definable syntax highlighting colors

Thanks to Cody Hoover (@hoovercj), you can now customize the editor syntax highlighting colors in user settings. This is a great way to easily adjust your editor colors without creating a full color theme.

Token Color Customization

The new color will be applied on top of the current theme. It will applied live and no reloading of VS Code is required.

A pre-configured list of syntax tokens (‘comments’, ‘strings’, …) is available for the most common constructs. If you want more, you can do so by directly specifying TextMate theme color rules.

Advanced Token Color Customization

Check out the theme section in our docs for more details.

14.2.2 File Explorer sort order

Thanks to Dmitry Zabello (@foreverest), a new setting explorer.sortOrder configures how files and folders are sorted in the File Explorer. You can choose between:

  • filesFirst - Sort files before folders
  • mixed - Sort files and folders without separation
  • modified - Sort by last modified time
  • type - Sort by file type

This is how the Explorer looks like with explorer.sortOrder: mixed

Explorer Sorting

14.2.3 Launch Integrated Terminal from the File Explorer

The context menu item to open a folder in a terminal (Open in Terminal) now defaults to open the folder in the Integrated Terminal. You can configure this to point at the external terminal using the terminal.explorerKind setting.

14.2.4 Managing views

Now that VS Code supports custom views in the Explorer, it is useful to be able to customize their layout. With this release, you can now change the order and the visibility of the views in the:

  • Explorer view
  • Debug view
  • Extensions view

Views management

You can drag and drop sections reorder and context menus allow you to hide and display sections. Changes to views are persisted across VS Code restarts.

14.2.5 New setting to close window when last editor closes

There is a new setting window.closeWhenEmpty to control if the window (instance) should close when the last editor is closed. On macOS, it is typical application behavior that the instance should close when the last document is closed. If you want this behavior, you can enable the setting.

Note: The setting only has an impact for windows that have no folders opened.

14.2.6 Improved –wait support

VS Code can be configured as the editor for external programs such as Git (see our documentation ). For that purpose, the --wait command line argument is used to keep the VS Code instance open until the external program is closed. In this release, we re-implemented this feature to work around some known issues.

First of all, we will now remember which instance was opened with --wait and properly wait for that instance to close. This fixes annoying issues when --wait is used while VS Code is already running as well as when you open a first instance and then more windows afterwards without closing the first window. In addition, on macOS where closing a window typically does not quit the application, we are now also returning control to the process that started the instance once it gets closed.

Second, when you close the last editor of the instance that was opened with --wait, we will now close the window automatically. With that, you can just hit kb(workbench.action.closeActiveEditor) to close the window.

Note: If you always want to close the window when the last editor closes, check out the new window.closeWhenEmpty setting for empty windows.

14.2.7 New theme color for title bar border

If you are on macOS, we show a custom title bar at the top. A new color titleBar.border can now be defined in themes or settings to draw a border separating the title bar from the rest of the editor.

14.2.8 Compare dirty file with version on disk

Thanks to Tobias Friemel (@tfriem), a new action compares a dirty (unsaved) file to its version on disk to quickly see the recent changes:

Compare with Saved

You can find the action from the context menu of dirty files within the OPEN EDITORS view of the Explorer and also as global command Files: Compare Active File with Saved (kb(workbench.files.action.compareWithSaved)).

14.2.9 Font aliasing (macOS only)

A new setting workbench.fontAliasing was added (macOS) to control the font smoothing within the workbench and editor. By default, fonts are subpixel anti-aliased. Change the setting to antialiased to smooth the font on the level of the pixel, as opposed to the subpixel (this can make the font appear lighter overall). You can disable font smoothing if you set it to none (text will show with jagged sharp edges).

14.2.10 Remove entries from recently opened

A new action (X) now shows up next to each entry of the recently opened picker (kb(workbench.action.openRecent)) to remove that entry from the list.

Remove Recently Opened

14.2.11 Quick Open command with prefix

The existing command workbench.action.quickOpen can now receive a prefix as an argument to open the Quick Open picker with any text prefilled.

For example, you can configure a keybinding to bring up Quick Open with text prefilled like this:

{ "key": "cmd+o", "command": "workbench.action.quickOpen", "args": "my-prefix" }

As an extension author, you can programmatically execute the command and pass in arguments:

vscode.commands.executeCommand('workbench.action.quickOpen', 'my-prefix');

Thanks to cristianhosu (@cristianhosu) for helping out with this.

14.2.12 Search changes

We made a couple changes to the Search view that you should be aware of. If you have a single folder open, ./example will match the directory example/ at the top level of the open folder. And if you enter example, that will match every folder and file named example in the workspace. This is different from the previous default, which would have matched any file named example, but only a top-level folder named example.

You may also notice that we’ve removed the Use glob patterns buttons in the pattern include/exclude boxes. With the new ./ syntax, we think they were no longer necessary. See our search documentation for more details on searching with globs.

14.3 Integrated Terminal

14.3.1 Configure environment of terminal sessions

A new setting for each platform terminal.integrated.env.<platform> allows adding additional environment variables to new terminals:

"terminal.integrated.env.linux": {
  "PYTHONPATH": "~/packages"
}

14.3.2 Terminal switching

You can now quickly switch active terminals and rename them using the quick picker. Either use the command Terminal: Switch Active Terminal or type in term (with a space) in Quick Open.

Switch Terminals

14.3.3 Better terminal session names on Windows

We’ve cleaned up the default terminal names on Windows when launching a process from the initial shell. For example, running powershell.exe or cmd.exe in the terminal will now display the name as simply ‘powershell’ or ‘cmd’.

14.3.4 Additional delete word keybindings in the terminal

The Integrated Terminal now has default keys for deleting words:

Linux/Windows:

  • Ctrl+Backspace: Delete word before cursor
  • Ctrl+Delete: Delete word after cursor

macOS:

  • Alt+Backspace: Delete word before cursor
  • Alt+Delete: Delete word after cursor

These work by sending keystrokes to the shell and as a result, they don’t work on some Windows shells.

14.3.5 Force selection using Alt on macOS

Running programs in mouse mode within the terminal (like tmux) will intercept the mouse and therefore not allow you to make a selection. You can now hold the Alt key to force the mouse event to perform a selection rather than be sent to the terminal.

14.4 Tasks

14.4.1 Less and Sass compiler problem matchers

We added two new problem matchers to parse the output of the less and node-sass compilers to detect and display problems from within VS Code. They are named $lessc and $node-sass.

14.4.2 Tasks Status Bar display

We also added a Status Bar item for tasks which becomes visible as soon as a task is executed. Clicking on the tasks Status Bar display guides you to the output of an executed task.

tasks status bar

14.5 Node Debugging

14.5.1 Loaded Scripts Explorer

For the last few VS Code releases, it has been possible to search and open loaded scripts via the Open Loaded Script command, which used a simple Quick Pick UI.

In this release, we’ve added an Explorer to the Debug view that provides direct access to all scripts and updates automatically as more scripts are loaded by the runtime:

Loaded Scripts Explorer

In contrast to the limited Quick Pick UI, the Explorer supports concurrent debug sessions and the scripts are grouped according to folders if used in a multi-root workspace.

A second advantage of the Loaded Scripts Explorer is that it was implemented as an extension and shows a real world example of the new debug API and how to contribute to a tree view. You can find the implementation here.

14.6 Languages

14.6.1 Search in Markdown preview

A PR from Cody Hoover (@hoovercj) brings search to webview contents, including the Release Notes, Markdown preview, and extension README pages:

Find in a webview

14.6.2 Linkifying in the Markdown preview

The Markdown preview will now automatically convert URL-like text into clickable links. This feature can be disabled by setting "markdown.preview.linkify": false.

14.6.3 Support for Markdown preview plugins

We added support for Markdown preview plugins for styles, scripts and Markdown it extensions.

Preview styles

Extensions can contribute CSS to customize the look or layout of the Markdown preview:

Changing the Markdown preview style

The VS Code Github Style extension is a good example that demonstrates using a stylesheet to make the Markdown preview look like Github’s rendered Markdown.

Markdown it plugins

Extensions can add support for additional Markdown syntax by contributing a markdown-it plugin.:

Adding emoji syntax support to the Markdown preview using a markdown it plugin

You can see this in action with the VS Code Markdown Emoji extension which uses a markdown-it plugin to add emoji support.

Preview scripts

Finally, for advanced functionality, extensions may contribute scripts that are executed inside of the Markdown preview:

Adding mermaid diagram support to the Markdown preview using scripts

Above you can see the VS Code Markdown Mermaid extension adding scripts to create mermaid diagrams and flowcharts.

14.6.4 New Markdown Preview Security Settings

The Markdown preview now blocks HTTP images by default. A popup is shown in the preview window when content has been blocked. You can change the security settings of Markdown previews in the current workspace by clicking on this popup or using the Markdown: Change Preview Security Settings command.

Changing the markdown preview’s security settings

You can find more information about the new Markdown preview security levels in the VS Code Markdown documentation.

14.7 Extension Authoring

14.7.1 New API to extend the Markdown preview

Extension authors can now extend the Markdown preview. The new API offers three new contribution points for styles, scripts and markdown-it extensions.

14.7.2 Proposed API for storing credentials

There is a proposed (subject to change, behind a command-line flag) API for storing credentials in vscode.credentials. Basic read/write/delete operations are available that forward to the keytar node module that uses the different credential stores of the different operating systems as its backing store. Join the discussion on GitHub.

14.7.3 New API to open an editor or diff editor with a specific selection

We enriched the existing TextDocumentShowOptions with a new property selection: Range that can be used from the showTextDocument method as well as the vscode.diff command. When provided, the editor will reveal and select the provided range.

14.7.4 Debug API updates

The proposed Debug API from last release (vscode.debug.*) has been slightly modified and extended.

Debugging can be started with the startDebugging function which takes either a named debug or compound configuration, or an in-memory configuration. Since named configurations or variables are only defined in the scope of a folder, we had to add a folder argument. A new onDidStartDebugSession event indicates that a debug session has been started.

The currently active debug session is available as the variable activeDebugSession and changes are reported through the onDidChangeActiveDebugSession event.

Custom Debug Adapter Protocol requests can be sent to a debug session with DebugSession.customRequest and corresponding custom events are reported through the onDidReceiveDebugSessionCustomEvent event.

14.7.5 Debug Contributions

Contributing views to the Debug Side Bar

You can now contribute views to the Debug Side Bar.

"contributes": {
  "views": {
    "debug": [
      {
        "id": "extension.node-debug.loadedScriptsExplorer",
        "name": "Loaded Scripts",
        "when": "inDebugMode && debugType == 'node'"
      }
    ]
  }
}

Variable substitution in package.json will no longer be supported

We are planning to stop support for variable substitution in the program and runtime attributes of the debuggers contribution in package.json. The reason for this is twofold: first, it is hard to explain that variable substitution only works for two attributes and not for all attributes in package.json. Second, with multi-root folders, it is difficult to support this feature in a useful way.

We will deprecate variable substitution in this release and plan to drop the feature in August. If it is difficult for you to move off this feature, please speak up by commenting here.

14.7.6 Debug Adapter Protocol

New process event

A new process event has been added that conveys the process ID and other information about the process being debugged.

New enum value normal for presentationHint attribute

For completeness, the default value normal was added to the value set for the presentationHint attribute of type Source.

14.7.7 New API for multi-root workspaces

New APIs have been added for multi-root workspaces. The “single root workspace” workspace.rootPath variable is now deprecated. Extension authors should use workspace.workspaceFolders which is a WorkspaceFolder array representing the current list of folders opened in the editor. There is a new event that fires when a folder is added or removed and a function getWorkspaceFolder to find a workspace folder for a given resource.

14.7.8 Icon for root folders

Icon theme authors, please get ready for multi-root support: We added two new icon categories for VS Code: rootFolder and rootFolderExpanded that can be used to show root folders in a different way compared to other folders. For example, the File Explorer will use this icon as well as the list of recently opened workspaces.

Root Icon

14.7.9 Configuration scopes

You can now classify the settings you contribute to configuration extension points into following scopes:

  • window: Window specific configuration which can be applied to the VS Code window and can be configured in the User and Workspace settings.
  • resource: Resource specific configuration, which can be applied to the resources like files and folders and can be configured in the User, Workspace and Folder settings.
"configuration": {
  "type": "object",
  "title": "MyLint",
  "properties": {
    "mylint.enable": {
      "type": "boolean",
      "default": true,
      "description": "Control whether mylint is enabled for files or not.",
      "scope": "resource"
    }
  }
}

This classification is needed to configure settings impacting resources in a multi-root workspace through Configuration API.

14.7.10 Configuration API

The Configuration API is enhanced to support configuring settings at Global, Workspace and Folder levels in a multi-root workspace. Now you can ask for the configuration of a resource and inspect and update it in User, Workspace and Folder settings.

Here is an example of reading and writing the configuration of a resource in Folder settings in a multi-root workspace:

const uri = vscode.window.activeTextEditor.document.uri;
const configuration = vscode.workspace.getConfiguration('mylint', uri);
// Let value of `mylint.enable` is `false` in the settings of root folder containing `uri`.
let value = configuration.get('enable'); // value is `false`
await configuration.update('enable', !value, vscode.ConfigurationTarget.WorkspaceFolder)
value = configuration.get('enable'); // value is `true`

Note: There are no breaking changes to the existing Configuration API.

14.8 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 release (see 1.14.0 release notes).

During this sprint, we focused on making multi-root workspaces a first class concept.

14.8.1 Introducing “Workspaces”

A Workspace is a new concept that surfaces in the UI whenever you want to have multiple folders opened in a single window (instance). A workspace is a simple configuration file that describes the folders you want to have open in a window. For example, for VS Code development we typically use three folders very frequently:

Workspace File

As you can see from the screenshot above, the workspace configuration file also contains a section for settings. Any Workspace Setting that you configure will end up in this file too (see below for more details around Workspace Settings).

Once you add additional folders to an empty window or a single-folder window, we make this window into an “Untitled Workspace”. A window reload is currently required for this transition (see video below). In the future, we think that we can make this transition even smoother without a window reload.

Workspaces

14.8.2 Untitled Workspace

As long as you do not save a workspace, it will appear as an “Untitled Workspace”. We do not force you to save a workspace until you want to have it in a permanent location, for example, on your Desktop. Untitled workspaces are present as long as the window they are using is open. Once you close a window with an untitled workspace, we will ask you to save it if you plan to open it again in the future:

Save Workspace

14.8.3 Saved Workspaces

Saved Workspaces can be opened by double clicking the .code-workspace file or via the new Open Workspace… command under the File menu:

Open Workspace

You will also see a new action Save Workspace As… that allows you to save the workspace to any location on your disk. The file extension of a VS Code workspace is .code-workspace and in the future, we plan to make it easier to share these files by allowing relative paths for folders.

Workspaces show up in a similar way as folders. You can open them from the list of recently opened workspaces:

Recently Opened Workspace

Any workspace will have an extra (Workspace) suffix appended to the name.

14.8.4 Workspace Settings

As mentioned above, the new Workspace concept introduces a workspace configuration file that contains a section to configure your workspace settings. In a multi-root workspace, when you open workspace settings, we now show this file. This file also contains other sections which are not related to workspace settings. To make them less prominent, we dim them in the editor. In future, we would improve the experience by showing only the settings section just like in User settings.

Workspace Settings

14.8.5 Folder Settings

With multiple root folders in one workspace, it is possible to have a .vscode folder in each root folder defining the settings that should apply for that folder. You can open the folder settings in the Settings editor from the drop-down.

Settings Dropdown

Selecting the folder, opens the settings for that folder.

Folder Settings

Only resource specific settings are applied at Folder level and window specific settings are not. Default settings editor on the left shows only those settings that can be applied at Folder level. If window specific settings exist in Folder settings, then they are shown dimmed with an info icon.

Unsupported Setting

Refer to Configuration scopes to know about window and resource specific settings.

14.8.6 Multi-root debugging

When opening a multi-root workspace with multiple launch.json files, the Debug drop-down shows all configurations (with the originating folder in parentheses):

multi-root debug

Variables used in a configuration (for example ${workspaceRoot}) are resolved relative to the folder they belongs to.

Thanks to a PR from Keegan Carruthers-Smith, search results in a multi-root workspace are now grouped by folder.

multiroot search results

When you have a multi-root workspace open, you can choose to search in a single root folder by using the ./ syntax in the “files to include” box. For example, if you enter ./project1/**/*.txt, that will search for all .txt files under the project1/ root folder.

14.9 Windows 64 bit

Visual Studio Code 64-bit builds are now available on Windows for the Stable release! They come in the usual Setup Installer format as well as a ZIP archive. We will show a message box to guide you to install the 64-bit version on Windows. Below are the download links:

Stable Windows 64-bit: Installer | ZIP archive

Insiders Windows 64-bit: Installer | ZIP archive

Note: If you are using the Setup Installer, you’ll need to uninstall the 32-bit version before you install the 64-bit build.

Note: All your settings and extensions will be preserved when you upgrade to the 64-bit version.

14.10 Proxy server authentication

Authenticated proxies should work seamlessly within VS Code with the addition of PR #22369.

The authentication methods supported are:

  • Basic
  • Digest
  • NTLM
  • Negotiate

When using VS Code behind an authenticated HTTP proxy, the following authentication popup will appear:

proxy authentication

Note that SOCKS5 proxy authentication support isn’t implemented yet; you can follow the issue in Chromium’s issue tracker.

You can learn more about proxy server support and how VS Code uses the Chromium network stack in the new Network Connections in VS Code topic.

14.11 New commands

Key Command Command id
kb(workbench.files.action.compareWithSaved) Compare a dirty file with the version on disk workbench.files.action.compareWithSaved
kb(workbench.action.terminal.deleteWordLeft) Delete word left in terminal workbench.action.terminal.deleteWordLeft
kb(workbench.action.terminal.deleteWordRight) Delete word right in terminal workbench.action.terminal.deleteWordRight

14.12 New documentation

We update the https://code.visualstudio.com website at a different cadence than the product release, so you might have missed some of the recent additions.

14.12.1 Community

We’ve added a Community page to let you quickly engage through Twitter, Stack Overflow, and GitHub. There are also links to community created content about VS Code hosted on such sites as PluralSight, Scotch.io, and LinkedIn Learning.

community page

14.12.2 Tutorials

We’ve created tutorials for React, Angular, and Node.js Deployment to Azure. These tutorials walk you through creating sample projects and using VS Code for smart code editing and debugging.

nodejs tutorials

14.13 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:

These are the closed bugs and these are the closed feature requests for the 1.15 update.

Contributions to vscode-node-debug:

Contributions to vscode-chrome-debug:

Contributions to vscode-json-languageservice:

Contributions to vscode-css-languageservice:

Contributions to vscode-tslint:

Contributions to vscode-debugadapter-node:

Contributions to vscode-recipes:

Contributions to vscode-github-issues-prs:

Contributions to localization:

This is the fourth month since we opened community localization in Transifex. We now have more 300 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: Jonathan Menzel, Antoine Griffard.
  • Italian: Aldo Donetti, Luca Nardi.
  • German: Carsten Kneip.
  • Spanish: Roberto Fonseca, dtriana, Jorge Serrano Pérez, Alberto Poblacion, Christian Eduardo Palomares Peralta, Andy Gonzalez.
  • Russian: Valeriy Schepak, Nikita Gryzlov.
  • Japanese: Tomoaki Yoshizawa, EbXpJ6bp, Yosuke Sano, Yuichi Nukiyama, Yuki Ueda, Tempura sukiyaki.
  • Chinese (Simplified): Aifen Qin, 林昊, YF, Joel Yang, Zijian Zhou, Alan Tsai, Zijian Zhou, 陈嘉恺, Ricky Wang.
  • Chinese (Traditional): Alan Liu, Alan Tsai, Duran Hsieh, Ke-Hsu Chen, Wei-Ting(DM), Ricky Wang.
  • Portuguese (Brazil): Bruno Sonnino, Roberto Fonseca, Frederico Oliveira, Luan Moreno Medeiros Maciel, Rodrigo Crespi, Lucas Miranda.
  • Hungarian: Tar Dániel.
  • Turkish: Adem Coşkuner, Ata Binen, Ali Oğuzhan Yıldız.
  • Dutch: Gerald Versluis, Jeroen Hermans, Sander van de Velde, Jasper van Merle.
  • Indonesian: eka priya.
  • Polish: Patryk Adamczyk, Patryk Zawadzki, Albert, Mateusz Wyczawski, KarbonKitty.
  • Portuguese (Portugal): Mike C.

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

15 August 2016 (version 1.5)

15.1 1.5.3 Fully Translated Build

It took us 2 weeks longer than originally anticipated, but now it’s here: The 1.5.3 release is our August release fully translated into the 9 supported languages.

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

15.2 1.5.2 Recovery Build

We are releasing a 1.5.2 recovery build to fix several important issues:

  • 11702: Unable to bypass ssl verification any more for corp firewall
  • 11714: Terminal focus key binding is not working correctly after update to 1.5
  • 11742: Bug in cursor location within user snippets
  • 11754: ShowQuickPick does not fulfil the promises

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

15.3 1.5.1 Recovery Build

To fix an issue when the editor.fontSize is set to 0, we’re releasing a 1.5.1 recovery build.

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

15.4 August Release Summary

The VS Code team was hard at work during August and we are happy with the release and we hope you like it too. There are key updates to the UI, extension support, debugging and the extensibility APIs.

Here are some highlights:

  • Workbench: Bring the File Explorer to life with File Icon Themes. VS Code ships with two icon themes with more available on the Marketplace.
  • Debugging: The console [REPL] just got a whole lot more usable with IntelliSense for Node.js as well as debug protocol additions to support IntelliSense by other debug extensions. We also added support for multi-line input.
  • Extensions:
  • You can now quickly see an extension’s contributions (commands, settings, languages). Both for your installed extensions and those on the Marketplace.
  • Sort your Marketplace extension searches by installation count and ratings.
  • Turn on auto update or use Update All for your installed extensions.
  • Editor: New settings to control word wrap and auto save.
  • Quick Open: Performance improvements with Quick Open for large projects.
  • Extension Authoring: Expanded editor command API to support VIM emulation.

Note: We had planned to ship 1.5 fully translated. Unfortunately, there are some delays with the translations and we do not want hold this release. We will ship an update with all the translations soon.

15.5 Workbench

15.5.1 File Icon Themes

The File Explorer can now show file and folder icons. To enable file icons, pick a File Icon Theme:

  • Use the global menu File > Preferences > File Icon Theme (Code > Preferences on Mac).
  • Use the Preferences: File Icon Theme command in the Command Palette (kb(workbench.action.showCommands)).

By default, no file icon set is configured and the File Explorer doesn’t render icons. Once a File Icon Theme is selected, the choice will be persisted and used again on restarts of VS Code. In this release, file icons are only shown in the File Explorer, but we plan to use file icons in other places, for example in Editor tabs.

VS code ships with two icon themes and we expect the community to contribute many more themes.

None (Default) Minimal File Icons Seti File Icons
None/Standard Icon Theme Minimal Icon Theme Seti Icon Theme

Credit goes to Jesse Weed and all contributors to the popular Seti UI theme for the fantastic Seti UI icons and to Roberto Huertas for implementing an icon extension that made very clear how many of our users wanted icons.

15.5.2 Key binding support within the Integrated Terminal

A new setting terminal.integrated.commandsToSkipShell was added that contains an array of commands that skip processing by the shell and instead are processed by VS Code’s key binding system. This allows keys such as kbstyle(F1) to now work while focus is in the terminal.

15.6 Editor

15.6.1 Editor settings

There are several useful Editor settings in this release:

  • editor.renderLineHighlight - Disables the current line highlight
  • editor.fontWeight - Customizes the editor’s font weight (normal, bold).
  • editor.wordWrap - Toggles word wrapping while respecting editor.wrappingColumn.

15.6.2 Auto Save when application loses focus

You can now configure Auto Save (files.autoSave setting) with the new value onWindowChange to trigger save automatically when switching windows.

15.6.3 Quick Open got a lot quicker

Over the last two iterations, we looked into making Quick Open fast, even for large workspaces (‘large’ as in ‘Chromium-repository-large’). A newly cloned Chromium repository contains more than 220,000 files. On our development machines, Quick Open went from around 30s in VS Code version 1.3 to around 3-4s (depending on your platform) in version 1.5. This is the performance without any caches. However we do use caches and with those, it takes around 0.5s to get the results. Since we start updating the caches immediately when the user invokes Quick Open and don’t block the UI thread when we read from the caches, the 0.5 seconds is the perceived end-user performance even when the caches were out-of-date. As said, this is for the large Chromium repository. If your projects are smaller, you may not see any delay now.

15.6.4 Keep Quick Open visible even when focus is outside

We added a new setting workbench.quickOpen.closeOnFocusLost to control if Quick Open should close when focus moves out of the widget. By default, Quick Open will close, but you can set it to false to stay open even when focus is outside of VS Code.

15.6.5 Include symbol results in file Quick Open results

We added a new setting search.quickOpen.includeSymbols to control if symbols should appear in Quick Open file searches. Previously, we included symbol results in the general file picker but this had enough issues that we decided to make this optional. If you want the symbol results back, please set this option to true. Note that enabling this setting will make the overall file search speed slower depending on the time it needs for the global symbol search to return results.

Note: You can always search for global symbols using Show All Symbols (kb(workbench.action.showAllSymbols)).

15.6.6 New actions to move Tabs left or right within a group

There are new actions to move a Tab (tabbed header) left or right within a group of editors.

The two actions and their default key bindings are:

Action Command Palette Key Binding
workbench.action.moveEditorLeftInGroup Move Editor Left kb(workbench.action.moveEditorLeftInGroup)
workbench.action.moveEditorRightInGroup Move Editor Right kb(workbench.action.moveEditorRightInGroup)

15.6.7 Closed editors reopen at their previous index

We always provided an action to reopen an editor after it was closed, workbench.action.reopenClosedEditor (kb(workbench.action.reopenClosedEditor)). With this release, editors will now reopen at the same index, preserving the order that existed before they were closed.

15.6.8 Mac OS: Cmd+E no longer opens Quick Open

We decided to remove an (undocumented) key binding to bring up quick open for file search. You can bring back kbstyle(Cmd+E) with the following key binding configuration:

{ "key": "cmd+e", "command": "workbench.action.quickOpen" }

The reason behind this change is that kbstyle(Cmd+E) on Mac OS is typically associated with running a search in the current active file.

15.7 Languages

15.7.1 TypeScript

We bundle the officially released version of TypeScript with Visual Studio Code. For the August release, this will be version 1.8.10. During September, the version 2.0 will become available and you can already install the release candidate using npm install -g typescript@rc. Using a different version of TypeScript inside VS Code as on the command line or by a build tool is confusing, since you will get different errors. 2.0 supports features that are not supported in 1.8.10. If you want to use the newer version of TypeScript inside VS Code then please use the typescript.tsdk setting and refer to the corresponding documentation.

VS Code now checks if the workspace folder contains a custom TypeScript version (typically installed via npm install typescript@x.x.x). If this is the case and the typescript.tsdk setting isn’t used, then VS Code informs the user about the local version and ask whether the local version should be used.

TypeScript Version Check

The More Information action takes you to documentation for how to configure VS Code to always use a locally installed TypeScript version. VS Code now also checks whether the used TypeScript language server is different than the globally installed tsc compiler. When this is the case, a corresponding information message is shown.

15.7.2 HTML

New settings have been added to control which built-in code completion providers are active. Use these settings if you prefer not to see the corresponding proposals.

// Configures if the built-in HTML language suggests Angular V1 tags and properties.
"html.suggest.angular1": true,

// Configures if the built-in HTML language suggests Ionic tags, properties and values.
"html.suggest.ionic": true,

// Configures if the built-in HTML language suggests HTML5 tags, properties and values.
"html.suggest.html5": true

15.7.3 LESS

The LESS syntax validation has been brought up-to-date to support some of the features recently added to LESS. These include:

  • Named Parameters in Mixins
  • Mixins as functions
  • Passing Rulesets to Mixins
  • CSS Guards
  • Merge

Check out the LESS documentation to learn more about these features.

15.7.4 Settings to enable/disable Emmet for languages

You can now associate existing Emmet syntax profiles (such as html, css) with other languages with the new emmet.syntaxProfiles setting. The setting takes a language Id and associates it with an Emmet profile.

For example, to use Emmet HTML abbreviations inside JavaScript:

{
    "emmet.syntaxProfiles": {
        "javascript": "html"
     }
}

You can disable Emmet abbreviations for a particular language using the emmet.excludeLanguages setting. The setting below disables Emmet in PHP files:

{
    "emmet.excludeLanguages": [
        "php"
    ]
}

15.7.5 Linter Extensions

The vscode-eslint and vscode-tslint extensions now provide settings to run the linter only on save and not while typing.

{
    "tslint.run": "onSave"
}

15.8 Extensions

15.8.1 Easier Updates

There is now an action to Update All Extensions.

Extension update all

Additionally, there is now an extensions.autoUpdate setting which, when set to true, will let extension automatically update themselves without user intervention.

15.8.2 Extension Contribution Details View

When browsing extensions in VS Code, there is now a Contributions section which will display each extension’s contributions, even before installing the extension.

Extension Details

15.8.3 Extension Sorting

You can now sort extensions not only by install count, in the extensions view:

Extension sort

15.8.4 Marketplace Performance Improvements

The Marketplace has been revamped with a CDN, in order to improve download times and availability for extension queries and downloads.

15.9 Debugging

15.9.1 Suggestions in Debug Console

The Debug Console now shows suggestions while typing. Currently this is only available for Node.js debugging, but other debuggers can implement suggestions as well through the debug protocol.

Debug Console Suggest

15.9.2 Multi-Line Debug Console Input

The Debug Console input now expands to multiple lines when needed. The expansion can be triggered using kbstyle(Shift + Enter).

Debug Console Multiline

15.9.3 Multi-Level Variable Paging

Data structures with a large number of children are displayed in multi-level chunks. This results in better performance and makes it easier to traverse a large number of children.

Variable Multi Level Paging

15.10 Node Debugging

15.10.1 Launch debug target in Integrated Terminal

It is now possible to launch the Node.js debug target in the Integrated Terminal which helps when developing Node.js based command line applications that read from an interactive terminal and/or need to control their output on the terminal they are running in.

Since there are now three options where to run a node program (Debug Console, Integrated Terminal, External Terminal), we’ve deprecated the boolean launch.json attribute externalConsole and introduced a new attribute console which accepts these corresponding values: internalConsole, integratedTerminal, externalTerminal.

New launch attribute Attribute console

Note: Depending on what options you have configured for the internalConsoleOptions attribute, VS Code may decide to open the Debug Console which will hide the Integrated Terminal. To avoid this, please set internalConsoleOptions to neverOpen.

Note: In this release, every debug session creates a new Integrated Terminal. In the next release, we will reuse an existing Integrated Terminal if possible.

15.11 Extension Authoring

Note: The August release of VS Code still bundles the official version of Typescript which is 1.8.10. Extension development should be done using this version. We will support TypeScript 2.0.x for extension development in a future release.

15.11.1 Editor Commands

For the VIM extension to make good progress on their roadmap particularly on window scrolling and folding, we added the following editor APIs:

  • Scroll editor: Scrolls the editor up or down - See 9609.
  commands.executeCommand('editorScroll', {to: 'up', by: 'page', value: '1'})
  • Reveal line: Reveals the line at different logical positions in the editor - See 9609.
  commands.executeCommand('revealLine', {lineNumber: '10', at: 'top'})
  • Fold: Fold the content of the editor n levels above or below the current cursor position.
  commands.executeCommand('editor.fold', {levels: '2', up: false})
  • Unfold: Unfold the content of the editor n levels below the current cursor position.
  commands.executeCommand('editor.unfold', {levels: '2'})

15.11.2 Powerful Completion Items

The Completion Item now supports additional text edits and an additional command.

With those, you can do rich things like:

  • Add an import statement when completing a symbol.
  • Add a library to the project when completing.

15.11.3 Stable Input Box and Quick Open

When showing Quick Open or asking for input, you can provide the ignoreFocusOut option so that the dialogs will not close when focus moves to another part of VS Code or another window. Also, you can now programmatically close them using a cancellation token.

15.11.4 New context menu keys

We added new context keys for more control over key bindings and menu items:

  • explorerResourceIsFolder - Will reflect if a file or folder is selected in the Explorer.
  • resourceFilename - The name of the file currently active in the editor/Explorer.

15.11.5 New Theme Settings

In this release, we exposed the following internal colors as TextMate theme settings and now theme writers can customize them with their themes.

  • rangeHighlight: Background color of range highlighted, used by Quick Open and Find features.
  • selectionHighlight: Background color of regions highlighted while selecting.
  • inactiveSelection: Background color of selections when not in focus.
  • wordHighlight: Background color of a symbol during read-access, like reading a variable.
  • wordHighlightStrong: Background color of a symbol during write-access, like writing to a variable.
  • findMatchHighlight: Background color of regions matching the search.
  • currentFindMatchHighlight: Background color of the current region matching the search.
  • findRangeHighlight: Background color of regions selected for search.
  • activeLinkForeground: Color of active links.
  • hoverHighlight: Background color when hovered.
  • referenceHighlight: Background color of a reference when finding all references.
  • guide: Color of the indentation guides which indicate nesting levels.

15.11.6 Integrated Terminal API

An API has been added that provides extensions with some basic control over the integrated terminal like creating terminal(s) and sending text to them. See the window API reference page for a full description of the API.

15.11.7 Additions to the Debug Protocol

The debug protocol has been extended in the following areas (and VS Code already provides the corresponding UI):

  • IntelliSense Support for the Debug Console: Debug adapters can now implement the completions request to provide suggestion proposals for IntelliSense in the Debug Console. To enable this feature in VS Code, a debug adapter has to set the supportsCompletionsRequest capability to true.

  • Run in Terminal Request: Debug adapters can now easily run the debug target in VS Code’s Integrated Terminal via the runInTerminal request (which happens to be the first request that is called from the debug adapter into VS Code). The Integrated Terminal is an alternative to the Debug Console and better supports development of command line applications that read from an interactive terminal and/or need to control their output on the terminal they are running in. Before calling runInTerminal make sure that the front-end client supports it by verifying that the arguments passed to the initialize request have a supportsRunInTerminalRequest attribute and that its value is true.

15.12 Engineering

Originally started with PR #9791 from Manoj Patel (@nojvek), we now have test coverage for our TypeScript files updated on each build.

15.13 Notable Changes

  • 6602: Add scroll bar to integrated terminal
  • 8499: Cannot distinguish different files with the same path.filename(x)
  • 8983: Closing a dirty split editor (existing OR untitled) should not affect the initial editor
  • 9405: Resizing terminal only resizes the active terminal instance
  • 9589: Save: Flush to disk after writing to file
  • 9675: Undo/Redo adds a stop in between CHN Characters
  • 9822: Terminal IME composition view appears on top of text when at the bottom of the screen
  • 9937: Increase rule stack protection limit - Syntax highlighting broken in JS with multiple nested functions
  • 9962: Explorer can freeze for large folders and many glob patterns
  • 10100: Terminal cursor does not invert text color
  • 10148: After updating to 1.4.0 the react-native extension no longer accepted as a debugger
  • 10302: Support standard keybindings for scrolling terminal by one line on each platform
  • 10360: File rename can close editors
  • 10586: TabCompletionController causes severe perf hit

These are the closed bugs and these are the closed feature requests for the 1.5 update.

15.14 Monaco Editor 0.6.0

We will create monthly releases of the “Monaco” Editor, in the same rhythm with VS Code. You can see the change log here.

15.15 Downloads

15.16 Thank You

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

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

Order: 16
TOCTitle: September 2016
PageTitle: Visual Studio Code September 2016 1.6
MetaDescription: See what is new in the Visual Studio Code September 2016 Release (1.6)
MetaSocialImage: 1_6_release-highlights.png

16 September 2016 (version 1.6)

16.1 1.6.1 Recovery Build

We are releasing a 1.6.1 recovery build to add the final 1.6 translations and fix several important issues.

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

16.2 September Release Summary

Welcome to the September release of VS Code. There are a number of significant updates in this version that we hope you will like, some of the key highlights include:

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

  • Workbench - View image dimensions & file size details.
  • Editor - Unicode improvements to support UTF-16 surrogate pairs, Improvements to Whitespace settings.
  • Languages - Updated TML/Razor/Handlebar support.
  • Extensions - Extension identifier badge, Extension update version check.
  • Debugging - Configurable External Terminal Support, Glob patterns for source maps.
  • Extension Authoring - Debug protocol updates including programmatic access to launch.json.

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

16.3 Workbench

16.3.1 Release notes inside VS Code

There is no need to go to our website to review the latest release notes - you can now see these directly within VS Code itself. Use the global Show Release Notes command or the Help > Release Notes menu to access them. Perhaps this is how you are reading these notes right now. :)

16.3.2 Icons Everywhere

Continuing on the work we did in the August release to support file icons, we’ve added file icons to many more places throughout the UI. This includes most trees that show files (for example, Problems panel, Search results, OPEN EDITORS section) as well as in Quick Open results and the editor headings.

If you don’t want to see icons everywhere, for instance in Tab headings, we added a new setting workbench.editor.showIcons.

Icons

16.3.3 Switch between running Windows

We added a new command to let you quickly move between open Windows of VS Code. Simply open the Command Palette (kb(workbench.action.showCommands)) and type Switch Window. A dropdown will appear showing all the opened VS Code Windows (instances) and you can quickly move from one to the other without leaving the keyboard, right from within VS Code.

switch window

16.3.4 Image dimensions & Binary file size

When you open a binary file in VS Code, extra meta information is now displayed in the Status Bar. For all binary files, we show the size of the file and for images, we also show the image dimensions.

Status

VS Code also now detects image file changes on disk so you no longer see stale old versions of an image.

16.4 Editor

16.4.1 Format On Save

Would you like your source code formatted each time you save? VS Code now supports “Format On Save” which will automatically pick up relevant installed formatter extensions and format the whole document on each save. Enable “Format On Save” by setting "editor.formatOnSave": true

Note: To keep cursors and selections stable, we don’t format when saving after delay.

16.4.2 Search term history

You can now navigate to your previous search terms in the global Search View and in the editor Find widget.

  • kbstyle(Alt+Up) navigates backward in the history. Corresponding commands are search.history.showPrevious and find.history.showPrevious.
  • kbstyle(Alt+Down) navigates forward in the history. Corresponding commands are search.history.showNext and find.history.showNext.

16.4.3 Hover & IntelliSense UI consistency

The Hover widget UI was updated aligning it more with VS Code’s IntelliSense experience:

hover

16.4.4 Auto Save Menu Item

Auto Save is a great feature for many scenarios. In order to make this feature more discoverable, VS Code now has an Auto Save toggle right in the File menu. This will toggle the files.autoSave setting in your global User settings.json configuration file.

16.4.5 File Associations configuration

It is tedious to repeatedly set the Language Mode of a given file type and configuring a file association mapping was a manual process through your user or workspace settings. Now when changing the Language Mode of a file, you can pick Configure File Association for… and your choice will be stored to your User settings file and remembered.

16.4.6 Unicode improvements

VS Code now has better handling of UTF-16 surrogate pairs and validates all edits such that it doesn’t break up the surrogate pairs. This is particularly important if you want to add things like Emojis into your source code.

16.4.7 Improvements to LineNumber and Whitespace settings

Several editor settings have been updated to support new options:

  • editor.renderWhitespace Possible values are now "all", "boundary" and "none". The "boundary" option does not render single spaces between words.

  • editor.lineNumbers Possible values are "on", "off" and "relative". "relative" shows the line count from the current cursor position.

16.5 Languages

16.5.1 TypeScript 2

VS Code 1.6 now ships with TypeScript 2.0.3. You can do the following to go back to TypeScript 1.8.10 in your workspace:

  • Navigate into your workspace folder.
  • Run npm install typescript@1.8.10 to install TypeScript version 1.8.10.
  • Start VS Code. You will get prompted whether you want to use the workspace version (1.8.10) or the bundled version (2.0.3) of TypeScript. Select workspace version and confirm the typescript.tsdk Workspace setting change.

16.5.2 TypeScript

TypeScript 2.0.3 contains lots of new features, like strict null checking or modular library dependencies to name a few. A complete list of the new features can be found here.

Besides new features, TypeScript 2.0.3 contains many bug fixes. This might result in additional compile time errors when you first compile your project with TypeScript 2.0.3.

16.5.3 JavaScript

The JavaScript in VS Code is powered by TypeScript and the TypeScript version bundled with VS Code has been updated to version 2.0.3.

This brings several improvements for JavaScript support:

  • The JS Doc support has been improved and many issues have been fixed.
  • The parser now allows any syntax that the TypeScript parser is capable of recognizing and is part of a JavaScript standards proposal. For example, static class properties are no longer flagged as invalid.

In addition, there are improvements to TypeScript that are also applicable to JavaScript:

One very big improvement is that the acquisition of Type Declaration files (typings) has been simplified. You can now use NPM directly to get typings with the @types parameter.

For example to get typings for lodash you can run:

npm install --save-dev @types/lodash

16.5.4 PREVIEW TypeScript JavaScript Grammar

The TypeScript/JavaScript TextMate grammar has been reworked for improved syntax highlighting. This work is currently available as an extension in the marketplace. The plan is to switch to this version during October. Please install this extension now and provide us with feedback.

16.5.5 Updated HTML/Razor/Handlebar Support

Since we made VS Code available, we’ve had the debt item that some languages were implemented inside VS Code directly and they were not implemented as an extension. In the last couple of milestones, we have reduced this debt by extracting the JSON, CSS, LESS, SASS languages into their own extension. In September, we have now done this for HTML and its coupled languages, Razor and Handlebar. These languages are now all implemented using the language server protocol.

This is a major refactoring and as a consequence, some language features have not yet been implemented:

We will work on bringing these features back during the next iteration.

However, we are not done yet.. Now that we have extracted languages into extensions, the next challenge is to support the nesting of these languages, that is, embed JavaScript or CSS inside HTML. We will be working on this in October.

16.6 Extensions

16.6.1 Workspace Extension Recommendations

Often you have a set of extensions that makes working with a particular workspace more productive. We now support creating a recommended list of extensions for a workspace. The set of recommendations is defined in a file extensions.json which is located in the .vscode folder. In this way, the recommendations can easily be shared inside a team.

You can create this file using the Extensions: Configure Workspace Recommended Extensions command.

For example, this is the extensions.json file that we use for the vscode workspace:

{
    "recommendations": [
        "eg2.tslint",
        "dbaeumer.vscode-eslint",
        "msjsdiag.debugger-for-chrome"
    ]
}

As you can see from the recommendations setting above, we recommend that anybody working on the VS Code codebase use the TSLint and ESLint extensions. In addition, we recommend using the Chrome debugger extension.

VS Code prompts a user to install the recommended extensions when a workspace is opened for the first time. The user can also review the list with the Extensions: Show Workspace Recommended Extensions command.

Show Recommendations

16.6.2 PREVIEW Extension Packs

We have added support for publishing ‘Extension Packs’ in the Marketplace. An Extension Pack is a set of extensions that can be installed together. This enables easily sharing your favorite extensions with other users. Another use case is to create a set of extensions for a particular scenario like PHP development to help a PHP developer get started with VS Code quickly. The feature is available as preview with the understanding that more work is still needed.

An Extension Pack is represented as an extension that depends on other extensions. This dependency is expressed using the extensionDependencies attribute inside the package.json file.

For example, here is an Extension Pack for PHP that includes a debugger, language service, and formatter:

  "extensionDependencies": [
      "felixfbecker.php-debug",
      "felixfbecker.php-intellisense",
      "Kasik96.format-php"
  ]

When installing an Extension Pack, VS Code will now also install its extension dependencies.

16.6.3 Extension identifier badge

To ease in the discoverability of the identifier of an extension required for workspace Recommendations and extension packs, we have added a badge to the Extension details view. An extension is uniquely identified using its publisher name and extension name separated by a period ..

Extension identifier.

16.6.4 Extension update version check

Now you will only see an extension as outdated if there is a new version that is compatible with your VS Code installation available in the Marketplace.

Note: This is applicable only if the extension is published using the latest version of the vsce publishing tool.

16.7 Debugging

16.7.1 Configurable External Terminal

Running a debug target in an external terminal is now provided as a VS Code service to debugger extensions and we hope that this will result in widespread adoption. A useful side effect of this is that it is now possible to configure which terminal program to use via the existing terminal.external.windowsExec, terminal.external.osxExec, and terminal.external.linuxExec settings.

Note: In this release, only the built-in debug extensions have adopted this new feature.

16.7.2 Launch configuration supports ‘npm’ and other tools

A frequent feature request was to support running ‘npm’ scripts directly from a launch configuration. This is now possible by the following changes to the existing launch configuration concepts:

  • Any program available on the PATH (for example ‘npm’, ‘mocha’, ‘gulp’, etc.) can now be used for the runtimeExecutable attribute and arguments can be passed via runtimeArgs.
  • The program attribute is no longer mandatory which helps if the npm script already specifies the program to launch.
  • If you specify a debug port via the port attribute, the --debug-brk=nnnn attribute will no longer be automatically added because the debug port is typically specified by the npm scripts as well.

Let’s look at an ‘npm’ example. If your package.json has a ‘debug’ script, for example:

  "scripts": {
    "debug": "node --nolazy --debug-brk=5858 myProgram.js"
  },

the corresponding launch configuration would look like this:

{
    "name": "Launch via NPM",
    "type": "node",
    "request": "launch",
    "cwd": "${workspaceRoot}",
    "runtimeExecutable": "npm",
    "windows": {
        "runtimeExecutable": "npm.cmd"
    },
    "runtimeArgs": [
        "run-script", "debug"
    ],
    "port": 5858
}

Note: On Windows, make sure to specify the executable with the correct extension, for example use npm.cmd instead of just npm which exists but is the shell script for Linux and macOS.

16.7.3 Glob pattern support for Source Map setup

When debugging transpiled code (for example TypeScript) where your build process generates JavaScript code into a specific directory, it is necessary to help the Node.js debugger finding the generated code. In previous version of VS Code, this was done by specifying the root directory of the generated source code via the outDir attribute.

In the September release, it is now possible to use multiple glob patterns for including and excluding files from the set of generated JavaScript files. For this, a new array typed attribute outFiles has been introduced. The old outDir is still supported, but we plan to deprecate this in the future.

The following example shows how to configure source maps if the generated code lives in an “out” and “node_modules” directory and you want to exclude the generated test code:

{
  "sourceMaps": true,
  "outFiles": [
    "${workspaceRoot}/{out,node_modules}/**/*.js",
    "!${workspaceRoot}/out/tests/**/*.js"
  ]
}

16.7.4 Experimental Node Debugger

We now have an experimental debug extension that uses the V8 Inspector Protocol, which Node.js now exposes via the --inspect flag, only in Node.js versions 6.3+. This is the same protocol exposed by Chrome and other targets. This extension runs on the vscode-chrome-debug-core library which also powers the Debugger for Chrome extension, and several others.

Note On Windows, the 6.x versions only support this in 32-bit versions of Node.js. The latest builds of v7 should work in 64 or 32-bit. See this issue.

This extension will eventually have feature-parity with vscode-node-debug, but isn’t there yet. An overview is recorded here and you can see issues in the vscode-node-debug2 repo and the vscode-chrome-debug-core repo. For the most part, you should be able to set "type": "node2" in your existing Node.js launch configuration and have things work the same, as long as it’s running in Node.js v6.3+.

Note: See troubleshooting tips in the extension README.

16.8 Extension Authoring

16.8.1 Authoring in TypeScript

The Yeoman generator for VS Code extensions has been updated to use TypeScript version 2.0.x. If you start a new VS Code extension, simply install yeoman and the extension generator using npm install -g yo generator-code and run it using yo code. If you have an existing extension using TypeScript 1.8.x, you can migrate it to TypeScript 2.0.3 using the following steps.

Open the package.json file and do the following changes:

  • Change the TypeScript developer dependency from "typescript": "x.x.x" to "typescript": "^2.0.3".
  • Add a developer dependency for the Node.js typings using "@types/node": "^6.0.40".
  • If your extension has Mocha tests, change the developer dependency to at least Mocha version 2.3.3.
  • Add a developer dependency for the Mocha typing using "@types/mocha": "^2.2.32".
  • In the script section, exchange the compile script with "compile": "tsc -watch -p ./" and the vscode:prepublish with "vscode:prepublish": "tsc -p ./".

The devDependencies section should look like this:

"devDependencies": {
    "typescript": "^2.0.3",
    "vscode": "^1.0.0", // Or a higher version if necessary
    "mocha": "^2.3.3",
    "@types/node": "^6.0.40",
    "@types/mocha": "^2.2.32"
}

and the scripts section something like this:

"scripts": {
    "vscode:prepublish": "tsc -p ./",
    "compile": "tsc -watch -p ./",
    "postinstall": "node ./node_modules/vscode/bin/install"
}
  • Open the tsconfig.json file and exchange the line "noLib": true with "lib": [ "es6" ] and "target": "es5" with "target": "es6".

The file should look something like this:

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es6",
        "outDir": "out",
        "lib": [
            "es6"
        ],
        "sourceMap": true,
        "rootDir": "."
    },
    "exclude": [
        "node_modules",
        ".vscode-test"
    ]
}

Then delete the typings folder in the workspace and run npm install from a terminal.

16.8.2 Authoring in JavaScript

The Yeoman generator has also been updated to make use of the new TypeScript 2.0.x features to help write JavaScript. If you want to migrate an existing extension to use TypeScript 2.0.3 for JavaScript authoring do the following.

Open the package.json file and do the following changes:

  • Add a TypeScript developer dependency "typescript": "^2.0.3".
  • Add a developer dependency for the Node.js typings using "@types/node": "^6.0.40".
  • If your extension has Mocha tests, change the developer dependeny to at least Mocha version 2.3.3.
  • Add a developer dependency for the Mocha typing using "@types/mocha": "^2.2.32".
  • We also recommend using ESLint for linting JavaScript source code. To do so, add the following entry as a developer dependency as well: "eslint": "^3.6.0". In addition we recommend installing the ESLint extensions.

The devDependencies section should now look something like this:

"devDependencies": {
    "typescript": "^2.0.3",
    "vscode": "^1.0.0", // Or a higher version if necessary
    "mocha": "^2.3.3",
    "eslint": "^3.6.0",
    "@types/node": "^6.0.40",
    "@types/mocha": "^2.2.32"
}
  • Open the jsconfig.json file and exchange the line "noLib": true with "lib": [ "es6" ] and "target": "es5" with "target": "es6".

The file should look something like this:

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es6",
        "lib": [
            "es6"
        ]
    },
    "exclude": [
        "node_modules"
    ]
}

Please note that although the target is set to es6 you still have to import other modules using require statements. Node.js has no support yet for ES2015 modules.

16.8.3 New APIs

  • We added an onWillSaveTextDocument event that is fired before a document is saved to disk. It allows an extension to change the document before saving and enables features like remove unused imports on save, insert final newline, etc.

  • There is now WorkspaceConfiguration#update which allows extensions to add/update/remove configuration options. This should ease configuring the editor and extensions. For example, an extension would be able to configure a linter from a warning via a code action.

  • Terminal#processId returns a Thenable<number> containing the process ID of the terminal’s shell process (eg. bash or cmd).

  • window.createTerminal now includes parameters to set the path and arguments of the shell. This will allows an extension to consistently launch the shell of choice, for example a Python or PowerShell REPL.

  • window.onDidCloseTerminal is a new event that allows extensions to easily track when terminals are closed by the user. Currently, like the rest of the API, this is restricted to only terminals created by the API.

16.8.4 Breaking Change: Button order in messages

When using any of the methods showInformationMessage, showWarningMessage, and showErrorMessage, you could always pass in a set of strings to show as actions next to the message. Previously, the order of messages was reversed such as the action you passed in first was shown last. We fixed this unexpected behavior in this release and actions are now displayed in order. Please check your extension for usage of this API to see if you are impacted. We think that the new behavior is more natural and thus did not add code that would keep the previous behavior.

16.8.5 Breaking Change: Terminals are created in the background

As mentioned in the API documentation, the window.createTerminal and Terminal.sendText will now be created in the background. So whenever an extension wants to show their terminal in the terminal panel, it requires an explicit call to Terminal.show.

16.9 Debug Extension Authoring

16.9.1 VS Code Debug Protocol

The VS Code debug protocol specification is now maintained as a language neutral JSON schema instead of a TypeScript definition file. This schema can be used to generate client or server libraries for a specific language automatically. The project vscode-debugadapter-node contains a simple program to generate the TypeScript d.ts from the schema. This program can be used as a starting point for other languages.

16.9.2 External Terminal support for ‘runInTerminal’ request

Debug adapters can now easily run the debug target in an External Terminal via the runInTerminal request and passing a value external for the kind parameter. The External Terminal is an alternative to the Integrated Terminal and supports development of command line applications that read from an interactive terminal and/or need to control their output on the terminal they are running in. Before calling runInTerminal make sure that the front-end client supports it by verifying that the arguments passed to the initialize request have a supportsRunInTerminalRequest attribute and that its value is true.

16.9.3 Initial Configurations contributed by a command

It is now possible for a debug adapter to specify a command name as a value for initialConfigurations attribute of the debuggers contribution in the package.json file. The debug adapter extension can then register the specified command which will get called once the launch.json file is generated for the first time. The command needs to return the initial content of the launch.json file - this way debug adapters have more flexibility on customizing launch.json. Our example mock debug illustrates this: ‘initialConfigurations’ contribution and command registration.

16.9.4 Debug Protocol Additions

Debug adapters can now implement ‘hit count’ support for breakpoints. With this, a user can specify how many hits of a breakpoint to ignore before it ‘breaks’ the execution. The SourceBreakpoint and FunctionBreakpoint types now support an optional attribute hitCondition for passing a hit count expression to the debug adapter. To enable the UI for this feature in VS Code, a debug adapter has to set the supportsHitConditionalBreakpoints capability to true.

Note: In the September release, VS Code does not implement UI for editing the hit count condition.

16.10 Miscellaneous

16.10.1 New location for dirty indicator when Tabs are disabled

We decided to move the dirty (unsaved file) indicator over to the Close button when Tabs (tabbed headers) are disabled. This makes the experience consistent with other places where we replace the Close button with the dirty indicator (for example, inside OPEN EDITORS or when Tabs are enabled).

Status

16.10.2 Electron update

In this release, we decided to take a major update of the Electron framework. We now run with version 1.3.7 which brings big version increments to the Chrome rendering engine (from 49 to 52) and Node.js (from 5.10.0 to 6.5.0). This also means that all extensions can expect the full Node.js 6.5.0 runtime when running in this VS Code release. For a full list of changes in Node.js, please refer to the Node.js Changelog.

Note: We don’t recommend extensions to use native npm modules. But if you authored an extension that does use native modules, remember to recompile all of them.

16.10.3 Detecting a corrupt installation

We have found ourselves spending many hours investigating VS Code issues that were ultimately caused by corrupt VS Code installations. Some extensions directly modify (patch) the VS Code product in such a way that is semi-permanent (until the next update) and this can cause hard to reproduce issues.

We have therefore added a background check where we try to detect if the VS Code bits have been changed on disk. We are not trying to block VS Code patching, but we want to raise awareness that patching VS Code means you are running an unsupported version.

corrupt install

16.10.4 Built-in Extensions

It is now possible to bundle a selection of Marketplace extensions with VS Code. These extensions appear as Built-in extensions. This allows us to decouple bundled extension development from VS Code’s core development.

builtin

16.10.5 Improvements in Issue Reporting

Related to this, we often investigate issues that are caused by an installed extension. To help us with these investigations, we have enriched the Help > Report Issues action to seed the issue description with the list of installed extensions.

Please use this action when reporting issues so we have more information to help track down the problem and ultimately resolve the issue for you quicker.

16.10.6 macOS Sierra support

Apple recently released the final version of macOS Sierra and with the Electron update, we were able to fix some issues we had seen (fonts and icons did not look sharp on a Retina display). However, some users are seeing bad background artifacts in the editor the underlying issue is Chrome related and it seems to happen when you are using a custom color profile. There is a workaround, you can run VS Code with forced GPU rasterization to mitigate this issue:

code --force-gpu-rasterization

16.11 New Commands

Key Command Command id
Search
kb(find.history.showNext) Next Search Term find.history.showNext
kb(find.history.showPrevious) Previous Search Term find.history.showPrevious
kb(toggleSearchCaseSensitive) Toggle Case Senstive toggleSearchCaseSensitive
kb(toggleSearchRegex) Toggle Regex toggleSearchRegex
kb(toggleSearchWholeWord) Toggle Whole Word toggleSearchWholeWord
Integrated Terminal
kb(workbench.action.terminal.scrollUpPage) Scroll Up workbench.action.terminal.scrollUpPage
kb(workbench.action.terminal.scrollDownPage) Scroll Down workbench.action.terminal.scrollDownPage
unassigned Clear Terminal workbench.action.terminal.clear
Extensions
unassigned Update All Extensions workbench.extensions.action.updateAllExtensions
unassigned Open Extensions Folder workbench.extensions.action.openExtensionsFolder
Navigation
unassigned Focus Active Editor Group workbench.action.focusActiveEditorGroup
unassigned Switch Window (Instance) workbench.action.switchWindow
Help
unassigned Show Release Notes update.showCurrentReleaseNotes
unassigned Report Issues workbench.action.reportIssues

16.12 Notable Changes

  • 241: Windows: Jump list misses files and folders in the recent category when opened
  • 7470: Save file even w/o file changes - so that Nodemon, Gulp, Chokidar and other file watchers restart
  • 7817: Integrated terminal scrolling not working in oh-my-zsh
  • 7951: Images do not show updated when changed on disk
  • 8819: Allow to Ctrl+click in File > Open Recent to open in new window
  • 9354: Ability to remove file permanently (bypass trash)
  • 9448: Lower case drive letter in Open New Command Prompt command on Windows
  • 11049: Text cursor stops blinking in integrated terminal if you run external command
  • 11129: Hovering cursor over integrated terminal on Mac shows a low-contrast cursor
  • 11244: Scroll is gone after exiting vi in integrated terminal
  • 11275: Terminal.dispose should not show the panel if it is hidden
  • 11318 & 8365: Search and Problems views are now consistent with others in highlighting lines.
  • 11727: Goto declaration should store current cursor in navigation history
  • 11976: MarkerService and ProblemsView do not scale well and block UI thread
  • 12574: Terminal scroll bar appears on top after hiding and displaying it

These are the closed bugs and these are the closed feature requests for the 1.6 update.

16.13 Contributions to Extensions

Our team maintains or contributes to a number of VS Code extensions. Most notably:

16.14 Thank You

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

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

Order: 17
TOCTitle: October 2016
PageTitle: Visual Studio Code October 2016 1.7
MetaDescription: See what is new in the Visual Studio Code October 2016 Release (1.7)
MetaSocialImage: 1_7_release-highlights.png

17 October 2016 (version 1.7)

17.1 1.7.2 Recovery Build

We are releasing 1.7.2 today which includes a new version of the TypeScript Server (to 2.0.10). The update to the server will re-enable the Automatic Type Acquisition (ATA) feature by default for JavaScript users. This feature greatly improves the IntelliSense in JavaScript projects and removes the need to manually install TypeScript declaration files (.d.ts files). This feature is powered by a query to the npmjs service to retrieve relevant declaration files for used modules. More details in relation to this feature, including details on how to disable it are included in the relevant section of these release notes.

The 1.7.2 release also adds the final 1.7 translations and fixes several important issues.

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

17.2 1.7.1 Recovery Build

We are releasing a 1.7.1 recovery build to disable the automatic JavaScript typings file acquisition feature. We need to tune the acquisition to avoid unnecessary load on the NPM registry and we’re working closely with the TypeScript and npmjs.org teams. We expect to enable this feature in a future release.

If you’re curious about the details, you can read our blog post describing the event and NPM and VS Code’s mitigations.

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

17.3 October Release Summary

Welcome to the October 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:

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

  • Workbench - Some View states now persisted in user settings. Open multiple files from Quick Open.
  • Editor - Keyboard shortcuts reference, finer formatting control.
  • Languages - JavaScript and CSS improvements.
  • Extensions - New categories for Keymaps and Formatters for easier search.
  • Node.js Debugging - Multi-target debugging support, new debugging settings.
  • Extension Authoring - Support for extension CHANGELOG.md files. Add to the editor tab context menu.

17.4 Workbench

17.4.1 Horizontal layout

You can now change the layout of editor groups to be either vertical or horizontal. Both layouts behave the same as before allowing you to move and resize editors and editor groups.

Horizontal

To enable horizontal layout for the current workspace, use:

  • The View menu Toggle Editor Group Layout.
  • The Command Palette Toggle Vertical/Horizontal Editor Group Layout.
  • An action in the header of the OPEN EDITORS view.

toggle horizontal layout

There is also a keyboard shortcut (kb(workbench.action.toggleEditorGroupLayout)) to quickly switch between the two layouts.

Once you made your choice for the layout, we persist it for the current workspace and restore it after restart.

17.4.2 Toggle Maximized Panel

We have introduced a global workbench command that maximizes the size of the panel (80% of the total height). If the panel is already maximized, this command will shrink the panel to its previous size. This is really handy when you have lots of output to review quickly. This command is not currently bound to any keyboard shortcut but you can add easily your own keybinding.

17.4.3 Toggle Sidebar and Hide Status Bar now persisted in user settings

We changed some of the toggles in the View menu to update your user settings file instead of persisting their state in the browser. This will make it easier to restore the same state on a different machine by copying the settings file.

The following settings will now be changed in your user settings file when you change them from the View menu:

  • workbench.sideBar.location to control the position of the Sidebar (left or right)
  • workbench.statusBar.visible to control the visibility of the Status Bar

In addition, changing the Zoom level from the View menu now writes to window.zoomLevel.

17.4.4 Open multiple files from Quick Open

Thanks to Will Prater (@wprater), you can now open multiple files from Quick Open by just pressing the Right arrow key. This will open the currently selected file in the background and you can continue selecting files from Quick Open.

17.5 Editor

17.5.1 Keyboard Shortcuts Reference

Help > Keyboard Shortcuts Reference brings up a printable PDF reference sheet of VS Code command keyboard shortcuts. Keep this reference handy and you’ll be a VS Code power user in no time.

Here’s it is for macOS:

keyboard shortcuts pdf

Below are links to the three platform-specific versions:

Note: We also added a menu command to go to the Introductory Videos on code.visualstudio.com (Help > Introductory Videos).

17.5.2 Format Document / Format Selection

The editor now has two explicit format actions: Format Document (kb(editor.action.formatDocument)) and Format Selection (kb(editor.action.formatSelection)).

format on context menu

We also added new configuration options to enable/disable the default formatters for JavaScript, TypeScript, JSON, and HTML. Use these options when you have another extension installed that provides formatting for the same language.

We’ve added a new Formatters category to the Marketplace so you can easily search and find source code formatting extensions.

marketplace formatter extensions

17.6 Languages

17.6.1 Better JavaScript IntelliSense

Note: This feature was disabled in the 1.7.1 build. Read on to learn what’s coming in a future release.

VS Code uses the TypeScript language server to provide IntelliSense in JavaScript files. In the past, you had to create a jsconfig.json file. You also had to manually install typings (Type Declaration) files for all the modules and libraries you were using. That’s not an easy chore, particularly when you are a pure JavaScript developer.

We talked with our friends on the TypeScript team and they came up with “Automatic Type Acquisition”. ATA makes typings files almost invisible. A TypeScript language server that has ATA enabled watches your package.json files and automatically installs the typings files of all dependencies in a cache on your file system. It does the same when it finds references to well known client-side libraries. When you then invoke IntelliSense, the TypeScript server uses the typings files in the cache. The cache is shared between all your workspaces. Without a jsconfig.json file the TypeScript server assumes that everything in your workspace belongs to the same project.

We think this is so cool that we wanted you to get your hands on it as soon as possible. Our integration of ATA is still rough around the edges, but we decided to enable it by default. Should you experience issues, you can switch it off by setting typescript.disableAutomaticTypeAcquisition to true in your user settings.

Here are a few points you should be aware of when using ATA:

  • ATA is backward compatible. If you have a typings folder or you installed typings using npm, then those take precedence over the automatically acquired typings files.
  • ATA acquires the latest available version of the typings files. If you depend on an older version of a library or module then there can be discrepancies between the actual API exposed by the library or module and the API described in the typings file. If you require a specific version of a typings files, you can install it manually: npm install @types/<module name>@x.y.z.
  • An increasing number of npm modules bundle their typings files, meaning the only way to acquire the typings is by installing the module. ATA does not install npm modules for you, so you have to do it yourself.
  • There is a short delay between when a change is made to the dependencies in a package.json file and when the corresponding typings file is acquired and available for IntelliSense.
  • In the implementation, the ATA feature first queries npmjs for a module that includes a list of known declaration files. If your project includes any of these modules, their declaration files will be pulled down and added to the global cache.

17.6.2 CSS completions in HTML

You can now see CSS language features like code completion, validation and color annotation for CSS styles embedded within your HTML.

css intellisense in html

17.6.3 Improved TypeScript and JavaScript Grammar

TypeScript and JavaScript syntax highlighting is based on the TypeScript textmate grammar authored by the TypeScript team.
In the recent months the grammar has been completely rewritten.

The main goal was to tackle as many of reported issues as possible. Additionally, we wanted to provide a better experience with existing color themes by generating scopes closer to what other popular JavaScript grammars such as the Atom grammar do, while still supporting features like the JavaScript React syntax.

As a result of the effort, over 100 issues has been fixed, including the request to report variable and function references. We decided to take advantage of the new scopes and now also colorize variable and function references in our Default Dark and Light Plus themes. We hope you like it!

Note: If you have already been helping us testing the latest grammar using the Latest TypeScript and JavaScript grammar extension: You can uninstall that extension now.

17.6.4 Linter Extensions

The vscode-eslint and vscode-tslint extensions now provide settings to automatically correct fixable warnings on save.

{
    "eslint.autoFixOnSave": true,
    "tslint.autoFixOnSave": true,
}

Note: This setting is ignored when files.autoSave is set to afterDelay.

17.7 Extensions

17.7.1 Keymaps category

Keyboard shortcuts are vital to productivity and changing keyboarding habits can be tough. To help with this, we added two new extensions and introduced a new category Keymaps to the Marketplace. The purpose is to make it easier to switch between editors by removing the need to learn new keyboard shortcuts.

We built an extension for Atom and Sublime Text. We found some of the most popular keyboard shortcuts and would like your feedback on what we’re missing. If we missed a keyboard shortcut, please open an issue or make a PR in the repo.

Keymaps

Additionally, you can create your own keymap extension using the keybindings contribution point and adding it to the Keymaps category.

17.7.2 Formatters category

Many extensions exist that contribute source code formatting functionality. Some of the most popular formatters have more than 100K installs! We wanted to make it easier for you to find formatters so we added a new category to the Marketplace called, naturally, Formatters. Search on the Marketplace and install a Formatter today.

Here are a couple of our favorites:

17.7.3 Disable extensions

Often you have more than one workspace and various extensions installed to support these workspaces. Most of the times, these extensions are exclusive to a single workspace and not needed for others. For example, if you have JavaScript and Go language workspaces, you do not need the JavaScript linting extension in a Go workspace and vice-versa. With this release, you can now run only those extensions which you think are necessary for a workspace and disable rest of them. You can also disable extensions for the complete VS Code application, if you do not want to uninstall them and do not want them to run.

Disable Extension

You can also disable or enable all extensions with few clicks from VS Code.

Disable All Extensions

17.7.4 Extension packs

Last release we introduced ‘Extension Packs’ which are extensions that depends on other extensions. In this release, we added a new tab to the extension editor to show these dependencies which gets installed when installing the pack.

Extension Pack

When you uninstall an extension pack, all its referenced dependency extensions are also uninstalled.

17.8 Node Debugging

17.8.1 Simplified launch configuration

In order to make setting up Node.js debugging as easy as possible, we’ve tried to simplify the initial ‘launch.json’ experience:

  • Required but rarely changed attributes are now rendered in gray to make it more obvious that there is no need to change them for the most common scenarios.
  • Less frequently used attributes (with good default values) were removed from the initial configurations to reduce the ‘noise’. These attributes are still easily discoverable using IntelliSense.
  • Comments and a link to online documentation were added.
  • Online debugging documentation has been rewritten and improved.

launchjson

Note: Since we are only able to change the built-in Node.js debugger of VS Code, we are relying on the authors of the other debug extensions to do something similar (if needed).

17.8.2 Hit count conditional breakpoints

VS Code now supports setting a ‘hit count condition’ for a breakpoint (in addition to the ‘expression condition’ introduced some time ago). The ‘hit count condition’ controls how many times a breakpoint needs to be hit before it will ‘break’ execution.

HitCount

Whether a ‘hit count condition’ is respected and how the exact syntax of the expression looks like depends on the debugger extension used. In this milestone, only the built-in Node.js debugger supports hit counts (but we hope other debugger extensions will follow soon).

The hit count syntax supported by the Node.js debugger is either an integer or one of the operators <, <=, =, >, >=, % followed by an integer.

Some examples:

  • >10 break always after 10 hits
  • <3 break on the first two hits only
  • 10 same as >=10
  • %2 break on every other hit

17.8.3 Multiple target debugging

The October release contains an early implementation of ‘multi target debugging’, that is multiple debug sessions can be active at the same time within a single instance of VS Code (and a single project folder).

This feature helps with the following scenarios:

  • Debug an extension and its debug adapter and/or language server at the same time.
  • Debug a client and a server from a single project folder.
  • Debug a clustered program.

Note: In this milestone the focus was on getting the internal abstractions for multi target debugging right and not on how to surface this in a UI.
So the UI of multi target debugging and how it is set up is highly experimental and will definitely change over the next milestones.

To enable ‘multi target debugging’ create a new launch configuration with a type composite and add an array typed attribute configurationNames.
Under that attribute list the names of other launch configurations that should be launched in parallel.

After launching the composite configuration, the individual sessions show up as top level elements in the CALL STACK view.
Actions (e.g. all actions in the floating debug widget) are always performed on the currently selected session in the CALL STACK view.

multiDebug

17.8.4 Debug settings

We have introduced the following new settings:

  • debug.allowBreakpointsEverywhere - Allows breakpoints to be set in any file (and not only in those which are explicitly registered). This is useful if you want to debug a new (transpiled) language with an existing debugger (for example, the Node.js debugger).
  • debug.openExplorerOnEnd - Controls if the Explorer should be automatically opened at the end of a debug session.

17.9 Extension Authoring

17.9.1 Breaking Change: MarkedString[] semantics

API related implementations which return MarkedString | MarkedString[] have changed semantics. Each MarkedString will be visually separated from the others with a horizontal line. Both the HoverProvider and Decoration APIs are affected by this.

17.9.2 Changelogs

You can now display your extension’s CHANGELOG.md directly in the extension details view.

We recommend extension authors move any existing changelogs from their extension’s README.md to a separate CHANGELOG.md file. Similar to README.md, if the CHANGELOG.md is placed in the extension’s workspace root, it will be automatically included by the vsce publishing tool.

17.9.3 Provide menu entries for the editor tab context menu

We added an additional place where extensions can contribute menu entries, the context menu of an editor tab (this also works when tabs are disabled). The related menu path for contributing here is editor/title/context.

For example:

"commands": [{
    "command": "doSomething",
    "title": "Do Something"
}],
"menus": {
    "editor/title/context": [
        {
            "command": "doSomething"
        }
    ]
}

17.9.4 onDidChangeVisibleTextEditors event

We added an onDidChangeVisibleTextEditors event which fires whenever the list of visible editors changes.

17.9.5 Update Now: Using latest vscode.d.ts

As ever, the latest and greatest version of our extension API is defined in the vscode.d.ts file.

Note: when you update your extension to use an API version 1.7.0 or newer, make sure you use the latest version of the vscode-node-module (^1.0.3) and make sure to use TypeScript 2.0.

Please read here to learn how to migrate your existing extensions to the latest vscode module.

17.10 New Commands

Key Command Command id
kb(workbench.action.toggleEditorGroupLayout) Toggle editor group layout workbench.action.toggleEditorGroupLayout
unassigned Toggle Maximized Panel workbench.action.toggleMaximizedPanel
Formatting
kb(editor.action.formatDocument) Format document editor.action.formatDocument
kb(editor.action.formatSelection) Format selection editor.action.formatSelection
Integrated Terminal
kb(workbench.action.terminal.scrollToTop) Scroll to top workbench.action.terminal.scrollToTop
kb(workbench.action.terminal.scrollToBottom) Scroll to bottom workbench.action.terminal.scrollToBottom

17.11 Notable Changes

  • 929: Windows 10: focus is not put to window but taskbar blinks
  • 2814: Windows: Reveal in Explorer feature no longer bring the explorer window in front of vscode
  • 6466: Open in Command Prompt doesn’t open cwd when using cmder
  • 10210: Can’t copy the values of debugging elements such as exception messages
  • 11334 & 13229: Improvements to terminal IME support
  • 11431: RPM package lacks shortcut in PATH
  • 12036: VS Code is very laggy when used on a system with touchscreens
  • 12260: Not enough storage is available to process this command in terminal
  • 12969: HTML: comments inside a script tag no longer sensitive to script language
  • 13554: Integrated terminal occasionally wraps some lines
  • 14102: Fold the default settings by default and remember editor state

Due to 13919, file extension associations in Windows were broken. You’ll need to reset your file extension associations to open with VS Code.

These are the closed bugs and these are the closed feature requests for the 1.7 update.

17.12 Contributions to Extensions

Our team maintains or contributes to a number of VS Code extensions. Most notably:

17.13 Thank You

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

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

18 November 2016 (version 1.8)

18.1 1.8.1 Recovery Build

We are releasing a 1.8.1 recovery build to address a handful of key issues before the end of year. Thank you for helping us find them quickly!

  • Fixed scrolling in large minified files (#17208)
  • Resolved an issue with Copy command in certain contexts (#17232)
  • Fixed an issue with saving files on a mounted drive (#17345)
  • Fixed Quick Outline in Default Keyboard Shortcuts (#17376)
  • Removed ‘Focus Default Settings’ command from Command Palette (#17468)

VS Code will automatically update itself to 1.8.1 or you can download the release directly using the following links:

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

18.2 November Release Summary

Welcome to the November 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:

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

  • Workbench - New View picker, Integrated Terminal improvements, macOS themed title.
  • Settings - Search and easily edit settings, find Keymap extensions.
  • Editor - Git Clone, new editor settings, Sublime Text compatibility.
  • Languages - CSS apply rule, Markdown preview customization, TSLint and ESLint extension updates.
  • Debugging - Add launch configurations easily as snippets through IntelliSense.
  • Node.js Debugging - Just My Code, load environment variables from files, help for sourcemaps.
  • Extension Authoring - Strict Null checks, snippet completions, debugger extension updates.

18.3 Workbench

18.3.1 Hot Exit

VS Code now remembers your unsaved changes when you exit. Hot Exit will be triggered under the following cases:

  • All windows (instances) are closed.
  • On Mac, when you finally quit the application.
  • Window reload, no more saving to reload extensions!

When VS Code is next launched after a Hot Exit, all workspaces/files that are backed up will be restored. This also brings with it the ability to restore files if VS Code crashes, regardless of whether Hot Exit is enabled or disabled (via the files.hotExit setting). You can read more about how Hot Exit works, the design decisions behind the implementation, and what’s next for the feature on our blog.

18.3.2 View Picker

A new picker is added that shows Views, Panels, Output channels and Terminals and allows for easy opening of those. You can open it via the Open View command or by typing view followed by a space into Quick Open.

View Picker

On Windows and Mac, you can press kbstyle(Ctrl+Q) to bring up the picker. On Linux, you can reassign the key binding if you want (kbstyle(Ctrl+Q) is assigned to quitting on Linux). Pressing kbstyle(Ctrl+Q) and holding the kbstyle(Ctrl) key while pressing the kbstyle(Q) allows you to jump to an entry from the list and open it after you release the keys.

18.3.3 Terminal improvements

Several improvements were made to the Integrated Terminal:

  • Terminal copy and paste key bindings on Windows have changed to kbstyle(Ctrl+C) (when text is selected) and kbstyle(Ctrl+V) respectively.
  • The terminal will no longer scroll to the bottom when it receives output if you have scrolled up
  • kbstyle(Cmd+K) now clears the terminal when it has focus
  • A new setting terminal.integrated.scrollback enables changing the number of lines the terminal will remember before discarding

18.3.4 Mac: Custom themed title

On macOS, we are now drawing our own custom title instead of the native one to allow for the theme color to be picked up. This behavior can be changed with the new window.titleBarStyle setting. The new default is custom but you can set the value to native to go back to the old behavior after a restart.

18.4 Focus on your code

This release we’ve added features to help you focus on your highest priority, your source code.

18.4.1 Zen Mode

Per user requests, we have added Zen Mode to VS Code. Zen Mode lets you focus on your code by hiding all UI except the editor (no Activity Bar, Status Bar, Sidebar and Panel) and going to full screen. Zen mode can be toggled using the View menu, Command Palette or by the shortcut kb(workbench.action.toggleZenMode). If you prefer not to transition to full screen, that can be disabled via window.fullScreenZenMode. Double kbstyle(Escape) exits Zen Mode.

18.4.2 Configurable Activity Bar

The Activity Bar is home to all views shipped with VS Code (File Explorer, Search, Debug). Many people use it to quickly switch between views and to see information about a view (for example, the number of outgoing files on the Git view).

In this release, we improved the Activity Bar with several new features. First of all, it is now possible to reorder views using drag and drop. The order is kept and restored between restarts of VS Code. Second, you can now remove entries from the Activity Bar using the context menu on either the Activity Bar itself or the particular view to remove.

Removed views will still show up in the Activity Bar when opened but their icon will not be displayed when you switch to another view. This is similar to the well-known behavior of an application dock where you can pin applications to always show them or unpin them if you want the application icon to be removed once the application quits.

Scalable Activity Bar

Finally, if the window gets small enough so that all view icons cannot show, a new overflow menu was added to show the views in a dropdown:

Scalable Activity Bar

18.4.3 Hide the Activity Bar

A new setting workbench.activityBar.visible lets you hide the Activity Bar to the side of the view area.

Hidden Activity Bar

We also added a related entry to the View menu as well as in Command Palette. The related command has the id workbench.action.toggleActivityBarVisibility.

18.4.4 New setting to hide Close buttons on Tabs

We added a new setting workbench.editor.showTabCloseButton that will hide the Close buttons on tabs. Dirty indications are still visible at the same location but you will not accidentally close tabs with the mouse once enabled.

18.5 Settings

VS Code’s customization model is very simple in the form of a settings.json file which you edit to configure VS Code’s behavior. To discover available settings, we show Default Settings in a separate editor as well as provide IntelliSense in your opened global or workspace settings. From user feedback and usability studies, we learned that people were still having trouble working with their settings. In this release, we did some explorations to improve discoverability and the user experience for modifying settings and this resulted in the following improvements.

18.5.1 Search settings

One of the big reasons for showing the default settings is to let users search and discover settings. To facilitate this, the Default Settings editor now comes with a big Search bar where you can easily search for settings. In addition to showing and highlighting settings matching your search criteria, this will also filter out those settings which are not matching. This makes finding settings quick and easy.

Search Settings

18.5.2 Settings groups

We enhanced visual representation of Default Settings groups to make settings navigation more user friendly. We also introduced a new group of most commonly used settings.

Settings Groups

18.5.3 Quick Edit

We introduced actions inside the Default Settings and settings.json editors which will help you quickly copy or update a setting.

Settings Groups

18.5.4 One Side by Side Settings editor

Last but not least, we grouped the Default Settings and settings.json editors into one side by side editor. This addresses the issue of managing two editors for settings.

Explorations and improvements continue… Stay tuned to our next release plan.

18.6 Keyboard shortcuts

18.6.1 Key binding command arguments

We added support to invoke commands with arguments to the keybindings.json configuration file. This is useful if you often perform the same operation on a specific file or folder. Simply add a custom keyboard shortcut to do exactly what you want.

The following is an example overriding the kbstyle(Enter) key to print some text:

  { "key": "enter", "command": "type",
                    "args": { "text": "Hello World" },
                    "when": "editorTextFocus" }

The type command will receive { "text": "Hello World"} as first argument and add “Hello World” to the file instead of producing the default command.

We have added a command to list the most popular Keymap extensions which provide full sets of key bindings for popular editors or IDEs. To see the list, use File > Preferences > Keymap Extensions.

Recommended keymap extensions

18.7 Editor

18.7.1 Selection menu

We have added a Selection menu to the menu bar giving access to the most common selection and multi-selection actions:

Selection menu

18.7.2 Text search performance

We improved the performance of full text search by running our search code in multiple processes in parallel. Your searches should complete much faster, especially in large workspaces.

18.7.3 Git clone

There is now a new lightweight command to clone a Git repository into your machine and open it with VS Code. You can execute it from the Command Palette and searching for Git: Clone.

18.7.4 New editor settings

  • window.showFullPath - show the full path to an opened file in the window title instead of the workspace relative one.
  • files.insertFinalNewline - automatically add a newline at the end of files when saving.

The editor.renderLineHighlight setting has been updated to support new options:

  • line - Highlight the current line in the editor.
  • gutter - Highlight the line number in the gutter to the left of the current line.
  • all - Both gutter and line highlight.
  • none - No current line highlighting.

render line highlight

18.7.5 Accessibility improvements of diff editor

We enhanced the accessibility of the diff editor by adding + and - indicators for modifications in the diff editor. The feature is enabled by default and can be disabled by setting diffEditor.renderIndicators to false.

diff indicators

18.7.6 Sublime Text compatibility

We added four new commands which users from Sublime Text are familiar with:

  • Join Lines - editor.action.joinLines
  • Transpose characters around the cursor - editor.action.transpose
  • Transform to Uppercase - editor.action.transformToUppercase
  • Transform to Lowercase - editor.action.transformToLowercase

These commands are not bound to any keyboard shortcuts by default.

18.8 Snippets

18.8.1 Snippet Variables

In your custom snippets, you can now use variables. The syntax for variables is $name for simple variables and ${name:default} for variables with a default value. Variables evaluate to their value, the empty string, or, if present, their default value. When a variable is unknown, we insert it as a placeholder.

The following variables can be used:

  • TM_SELECTED_TEXT - The currently selected text or the empty string.
  • TM_CURRENT_LINE - The contents of the current line.
  • TM_CURRENT_WORD - The contents of the word under cursor or the empty string.
  • TM_LINE_INDEX - The zero-index based line number.
  • TM_LINE_NUMBER - The one-index based line number.
  • TM_FILENAME - The filename of the current document.
  • TM_DIRECTORY - The directory of the current document.
  • TM_FILEPATH - The full file path of the current document.

The following is an example of a snippet that surrounds the selected text with single quotes or, when no text is selected, inserts a type_here-placeholder.

"in quotes": {
    "prefix": "inq",
    "body": "'${TM_SELECTED_TEXT:${1:type_here}}'"
}

18.8.2 Snippets in JSON schemas

The JSON language service uses JSON schemas to validate JSON documents as well as to provide completions. As a VS code specific extension to JSON schemas, you can now also specify snippets proposals in the schema for a richer experience. The snippet proposals are shown as additional completion proposals and use the snippet syntax to specify placeholders.
See the JSON documentation for more information.

18.9 Languages

18.9.1 JavaScript language support in HTML

Coding assistance for JavaScript embedded in HTML is back! You get code completions and signature help for DOM and JQuery APIs, validation, hovers, Find References and Go To Definition, symbol highlighting and outline (Ctrl + Shift + o) and format. Note that the language support doesn’t follow script includes, it only knows about definitions made in the same file.

JavaScript editing in HTML

18.9.2 CSS improvements

The CSS language support can now handle the new @apply rule.

CSS in HTML was also improved, in particular for styles defined in attributes:

CSS in HTML attributes

18.9.3 TypeScript Update

We now use TypeScript 2.1 for JavaScript and TypeScript language support. TypeScript 2.1 brings a number of new language and tooling features. Read about what’s new in TypeScript 2.1.

18.9.4 JavaScript

The JavaScript in VS Code is powered by TypeScript and the new TypeScript version bundled with VS Code brings several improvements for JavaScript support:

  • Support for Object Rest and Spread. This was a heavily requested feature request by JS developers working with React. Now you no longer need to disable JavaScript validation when using Object Spread/Rest.
  • Configuration inheritance for jsconfig.json files.
  • IntelliSense for paths in import and require.

18.9.5 Markdown preview improvements

Several new settings were added to improve Markdown preview and let you more closely match your final Markdown rendering.

  • markdown.previewFrontMatter - By default, VS Code now hides YAML front matter sections in preview. You can set to show if you’d like to review YAML metadata.

Controls the font family, size and line height used in the Markdown preview.

  • markdown.preview.fontFamily
  • markdown.preview.fontSize
  • markdown.preview.lineHeight

18.9.6 Linter Extensions

18.9.6.1 vscode-tslint

The vscode-tslint extension now supports TSLint 4.0. This version of TSLint provides additional quick fixes for warnings. In addition, vscode-tslint adds a quick fix to disable a TSLint rule on the next line. The new TSLint version also adds support for linting JavaScript files. See the CHANGELOG for more details.

18.9.6.2 vscode-eslint

The vscode-eslint extension now supports validating file types other than JavaScript. To enable this, you need to do the following:

  • Configure ESLint with an additional plugin to do the actual validation. For example, to validate HTML files install eslint-plugin-html using npm install eslint-plugin-html and update the eslint configuration (e.g. .eslintrc.json file) with "plugin": [ "html" ].
  • Add the corresponding language identifier to the eslint.validate setting. Something like "eslint.validate": [ "javascript", "javascriptreact", "html" ]. If the setting is missing, it defaults to ["javascript", "javascriptreact"]

18.10 Debugging

18.10.1 Multitarget debugging

A first glimpse of multi-target debugging was already available in the previous milestone. In this milestone, we’ve added the user interface for it. With this release, multi-target debugging is no longer experimental.

Using multi-target debugging is very simple: after you’ve started a first debug session, VS Code no longer blocks you from launching another session. As soon as a second session is up and running, the VS Code UI switches to multi-target mode:

  • The individual sessions now show up as top level elements in the CALL STACK view.<BR>Callstack View
  • The floating debug widget shows the currently active session (and all other sessions are available in a dropdown menu).<BR>Debug Actions Widget
  • Debug actions (e.g. all actions in the floating debug widget) are performed on the active session. The active session can be changed either by using the drop down menu in the floating debug widget or by selecting a different element in the CALL STACK view.
  • Whenever a session stops (e.g. because a breakpoint or exception is hit), this session becomes the active session. This makes it possible to easily step between debug sessions just by pressing ‘F5’.

An alternative way to start multiple debug session is by using a so-called compound launch configuration. A compound launch configuration lists the names of two or more launch configurations that should be launched in parallel. Compound launch configurations show up in the launch configuration drop down menu.

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Server",
            "program": "${workspaceRoot}/server.js",
            "cwd": "${workspaceRoot}"
        },
        {
            "type": "node",
            "request": "launch",
            "name": "Client",
            "program": "${workspaceRoot}/client.js",
            "cwd": "${workspaceRoot}"
        }
    ],
    "compounds": [
        {
            "name": "Server/Client",
            "configurations": ["Server", "Client"]
        }
    ]
}

This blog explains in detail how to setup a compound configuration for a Node.js backend and a browser frontend.

18.10.2 Adding individual Launch Configurations

We’ve tried to improve the experience of adding new configurations to an existing launch.json by supporting snippet suggestions for IntelliSense. Snippet IntelliSense is available if your cursor is located inside the configurations array. Or just press the Add Configuration button to invoke snippet IntelliSense at the start of the array.

Add Configuration

IntelliSense lists the launch configuration snippets that are contributed by all installed debug extensions. This makes it really easy to combine launch configurations for different debuggers (e.g. Chrome and Node) into one launch.json.

Since debug extensions will have to opt into this new feature, please allow some time until all debuggers have adopted this. In the November release, only the built-in Node.js debuggers contribute snippets.

18.10.3 Some UI Polish

Per user request, we now support rearranging the order of Watch expressions using drag and drop.

We have polished the look of the debug start action UI by grouping the start button with the drop down menu to tie them together:

DebugStart

The source and line number information in the BREAKPOINTS view has been rearranged to better align with the CALL STACK view.

Breakpoints

18.11 Node Debugging

This section covers features of the two built-in Node.js debuggers, node and node2. We try to keep feature parity between them but this becomes more and more difficult because the technology underlying node (V8 Debugger Protocol) is deprecated (frozen) whereas the new technology (Chrome Debugger Protocol) evolves quickly. For this reason, we list the supported debugger types in parenthesis in the header of each feature.

Use the ‘old’ debugger node when debugging Node.js versions < 6.3 and the new debugger node2 for versions >= 6.3.

Note: If you are using ES6 Proxy in your Node.js app, a Node.js v7.x runtime might even crash when being debugged by the old debugger. This does not happen with node2. This issue is tracked in Microsoft/vscode#12749.

18.11.1 Just My Code (node and node2)

We have added a feature to avoid code that you don’t want to step through. This feature can be enabled with the skipFiles setting in your launch configuration. skipFiles is an array of glob patterns for script paths to skip.

For example using:

  "skipFiles": [
    "node_modules/**/*.js",
    "lib/**/*.js"
  ]

all code in the node_modules and lib folders will be skipped.

The exact rules are as follows:

  • If you step into a skipped file, you won’t stop there - you will stop on the next executed line that is not in a skipped file.
  • If you have set the option to break on thrown exceptions, then you won’t break on exceptions thrown from skipped files.
  • If you set a breakpoint in a skipped file, you will stop at that breakpoint, and you will be able to step through it until you step out of it, at which point normal skipping behavior will resume.

This feature is available in the node, node2, and Chrome debuggers.

Note: The old debugger (node) supports negative glob patterns, but they must follow a positive pattern: positive patterns add to the set of skipped files, while negative patterns subtract from that set.

In the following example all but a ‘math’ module is skipped:

"skipFiles": [
    "node_modules/**/*.js",
    "!node_modules/math/**/*.js"
]

Note: The old debugger (node) has to emulate the Just My Code feature because the V8 Debugger Protocol does not support it natively. This might result in slow stepping performance.

18.11.2 Load environment variables from external file (node)

The VS Code Node debugger now supports to load environment variables from a file and passes them to the node runtime.
To use this feature add an attribute envFile to your launch config and specify the absolute path to the file containing the environment variables:

   //...
   "envFile": "${workspaceRoot}/.env",
   "env": { "USER": "john doe" }
   //...

Any environment variable specified in the env dictionary will override variables loaded from the file.

Here is an example for an ‘.env’ file:

USER=doe
PASSWORD=abc123

# a comment

# an empty value:
empty=

# new lines expanded in quoted strings:
lines="foo\nbar"

18.11.3 Diagnostics for Source Map Problems (node2)

When debugging a Node.js app, you may have seen breakpoints turn gray with the message “Source map problem?”. The new node2 debug adapter has two new features which make it easier to understand these issues.

Typing .scripts in the debug console during a debugging session will cause the adapter to print out all the information it has about loaded scripts and their sourcemaps.

And the sourceMapPathOverrides option in the launch config allows you to rewrite paths in your sourcemap file to enable sourcemaps in cases where the sourcemap file doesn’t include enough information for the debug adapter to find the correct source files on disk. See more information about both of these features in the node2 README.

18.11.4 Back in time Debugging (node)

This UI appears automatically for Chakra based Node.js runtimes. For details see this blog.

The Back In Time Debugging support of the node debugger has been extended by a Reverse Continue action:

Reverse Continue

18.12 Extension Authoring

18.12.1 Strict Null Checks supported

We have updated the type definitions in vscode.d.ts to explicit spell out when a type can be undefined and/or null. With this extensions using the strictNullChecks-feature of TypeScript will get better type check results.

18.12.2 Snippet Completions

A completion item provider can now return completions that are inserted as snippet. When creating an item, make sure its insertText is a SnippetString. When selected, the editor will go to snippet mode, allowing the have placeholders and control over the cursor position.

18.12.3 Inspect Configurations

With the new inspect-function you can figure out where a configuration value was defined and what it default is.

18.12.4 TextDocument#getWordRangeAt

Ever since the text document allows to ask for a word-range at a given position. To know what a word is VS Code uses the word-pattern of the respective language. That’s not always good enough and therefore you can now provide a regular expression that will be used instead.

18.12.5 Debugger Extension Authoring

In the launch.json, the top level debugServer attribute has been deprecated (and support for it will be removed in the February milestone). Instead the debugServer attribute has to be specified per launch configuration. More details can be found here.

Debugger extensions can now contribute launch configuration snippets which will get surfaced in launch.json as explained in section “Adding Individual Launch Configurations”. This can be done using the regular syntax for contributing snippets to VS Code, but as a configurationSnippets attribute inside the debuggers section of the package.json. An example of how Mock Debug is contributing debug configuration snippets can be found here.

18.12.6 VS Code Debug Protocol

The OutputEvent type now supports to send structured objects to the debug console and VS Code renders them as expandable objects. More details can be found here.

A new RestartRequest has been added to the debug protocol. If a debug adapter opts into this, the VS Code debugger UI no longer implements the Restart action by terminating and restarting the debug adapter but instead sends a RestartRequest to the adapter. More details can be found here.

18.13 Miscellaneous

18.13.1 Electron update

In this release, we updated from Electron 1.3.x to 1.4.x. This brings a Chrome update from version 52 to 53. We have heard from users that this update reduces font blurriness on Windows when running with >100% DPI.

Another benefit is that we can now enable the High Contrast theme automatically when we detect that Windows is running in high contrast mode. VS Code will open in high contrast mode when Windows is configured as such and will also switch to high contrast mode if you change the mode in Windows while VS Code is running.

18.13.2 Language Server Protocol

The LSP now supports snippets in completion items just as the VS Code API does. In addition, two new requests got introduced supporting the dynamic registration of providers on the client side. Also the LSP NPM node modules were upgraded to TypeScript version 2.0. For details see https://github.com/Microsoft/language-server-protocol and https://github.com/Microsoft/vscode-languageserver-node

18.14 New Commands

Key Command Command id
kb(workbench.action.quickOpenView) Quick Open View workbench.action.quickOpenView
kb(workbench.action.nextEditorInGroup) Open Next Editor in Group workbench.action.nextEditorInGroup
kb(workbench.action.previousEditorInGroup) Open Previous Editor in Group workbench.action.previousEditorInGroup
kb(workbench.action.toggleZenMode) Enable Zen Mode workbench.action.toggleZenMode
kb(workbench.action.exitZenMode) Leave Zen Mode workbench.action.exitZenMode
kb(workbench.action.closePanel) Close active Panel workbench.action.closePanel
kb(workbench.action.git.clone) Clone from a Git URL workbench.action.git.clone
kb(workbench.action.toggleActivityBarVisibility) Toggle Visibility of Activity Bar workbench.action.toggleActivityBarVisibility
kb(workbench.action.quit) Quit VS Code workbench.action.quit
kb(editor.action.joinLines) Join Lines editor.action.joinLines
kb(editor.action.transpose) Transpose characters around the cursor editor.action.transpose
kb(editor.action.transformToUppercase) Transform to Uppercase editor.action.transformToUppercase
kb(editor.action.transformToLowercase) Transform to Lowercase editor.action.transformToLowercase

18.15 Notable Changes

  • 16330: Use cached data to speed up script parsing
  • 16065: First https request is responsible for 18% of windows startup time
  • 15111: External file watcher fails for editors that do atomic saves
  • 14951: Download vscode very slow in China
  • 13104: Windows: selected tree item not accessible
  • 13527: Text is super blurry now
  • 15741: Allow code to open directories in nautilus file manager

These are the closed bugs and these are the closed feature requests for the 1.8 update.

18.16 Contributions to Extensions

Our team maintains or contributes to a number of VS Code extensions. Most notably:

18.17 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-tslint:

Contributions to vscode-debugadapter-node:

Contributions to language-server-protocol:

Contributions to vscode-languageserver-node:

Contributions to vscode-css-languageservice:

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

19 January 2017 (version 1.9)

19.1 1.9.1 Recovery Build

We are releasing a 1.9.1 recovery build to update the 1.9 translations and address a handful of issues.

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

19.2 January Release Summary

Welcome to the first 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:

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

  • Workbench - New settings to control new windows, improved Tabbed headings, Zen Mode customization.
  • Editor - Add keyboard shortcut keys for snippets, Go to Implementation, fast search navigation.
  • Languages - Emmet abbreviations from external files, HTML format settings, Markdown editing improvements.
  • Extensions - Create Extension Packs through the VS Code Yeoman generator.
  • Debugging - User level launch.json, copy callstack action.
  • Node.js Debugging - Just My Code improvements, restart support for launch configurations.
  • Extension Authoring - New insertSnippet API, openTextDocument can now take language.

19.3 Workbench

19.3.1 Welcome experience

We have added a Welcome page (Help > Welcome) with Quick links to help new users as well as a list of Recent folders and Help documentation links for fast navigation.

Welcome document

Check the Show welcome page on startup option to keep it handy. The Welcome page is only shown if there are no open files on startup.

If you are a new user, you will appreciate the Interface overview available from the Welcome page. It calls out the basic parts of the user interface with their keyboard shortcuts:

Interface Overview

19.3.2 Interactive Playground

The Interactive Playground on the Welcome page introduces you in a step-by-step guide to some of our advanced code editing features with interactive examples:

Interface Overview

19.3.3 Integrated Terminal improvements

19.3.3.1 Performance

Much of the Integrated Terminal frontend has been rewritten with performance in mind. In short, it should no longer lock up the application when processing large amounts of data and be about 5 times faster.

Before (v1.8.1):


Terminal performance before

After (v1.9.0):


Terminal performance before

19.3.3.2 Windows support

The library used to communicate with the terminal process on Windows has been upgraded which fixes many of the problems the terminal had on Windows such as arrow keys not functioning and the prompt line going out of sync. A special thanks to Ryan Prichard for his winpty library and for assisting with the upgrade.

19.3.3.3 Other

  • PowerShell new default on Windows 10: PowerShell is now the default shell on Windows 10 to better align with the upcoming OS default. You can change this back to cmd.exe by setting terminal.integrated.shell.windows to "cmd.exe" in your settings.json file.
  • Right-click copy or paste: On Windows, similar to the cmd.exe feature, right clicking within the terminal will copy if there is a selection or paste if there is no selection. This is enabled by default on Windows and can be configured (on any platform) using the terminal.integrated.rightClickCopyPaste setting.
  • Cursor styles: New line and underline cursor styles have been added to the terminal, these can be configured with the terminal.integrated.cursorStyle setting.
  • Wide character support: Wide characters are now sized to consume exactly 2 character widths.
  • Better space utilization: The individual terminals within the terminal panel should now fill up as much space as possible.

19.3.4 Always hot exit on folders

The files.hotExit setting has changed from a simple true/false setting to accept the following options:

  • "off": Disable hot exit (same as the old false setting).
  • "onExit": Enable hot exit when all VS Code windows are shut down (same as the old true setting).
  • "onExitAndWindowClose": Same as "onExit" but trigger hot exit when any folder window closes, regardless of whether it’s the instance window or not. In order to enable more flexibility, this setting will also not restore folder windows when you next launch, "window.reopenFolders": "all" can be used to restore all previous windows when this setting is used.

19.3.5 Zen mode improvements

To reduce visual clutter, Zen mode now also hides the workbench Tabs. We have also introduced the following options to make it easier to fine tune the Zen mode experience:

  • "zenMode.hideStatusBar" - Set to false, if you don’t want Zen Mode to hide the Status Bar.
  • "zenMode.hideTabs" - Set to false, if you want to still see Tabs.
  • "zenMode.fullScreen" - Set to false to not go to full screen, had been workbench.fullScreenZenMode.

19.3.6 Search result navigation

There are two new ways to easily navigate results in the Search view.

  • The arrow keys - When you use the arrow keys to select a result, it will be shown in the editor.
  • Two new commands: search.action.focusNextSearchResult and search.action.focusPreviousSearchResult - By default, these are bound to kb(search.action.focusNextSearchResult) and kb(search.action.focusPreviousSearchResult).

search result navigation

19.3.7 Panels title bar update

The title bar of the horizontal panel now shows all the other available panels and thus makes it much easier to switch between panels.

Panels

19.3.8 New entries in the context menu of Tabs

Additional entries have been added to the context menu of Tabs that show files. You can copy the path of the file or reveal it in the native OS Explorer or the Explorer in the Side Bar.

Tab Context Menu

19.3.9 New setting to control close button in Tabs

We added a new setting workbench.editor.tabCloseButton that controls if the close button should show on the right (default), left or not be visible at all.

Tab Close Button on the Left

Note: The previous workbench.editor.showTabCloseButton was removed in favor of this new option.

19.3.10 Control whether to open a new window or use last active

When VS Code is already running and you open a new file or folder, it decides whether to open in the last active window or a new window. The existing window.openFilesInNewWindow setting controls this for files and by default, a new window would be opened. With this release, we wanted to make this more configurable and also change the default behavior for opening files.

  • Added window.openFoldersInNewWindow to configure this behavior for folders.
  • Changed the possible values to default, on and off. ( window.openFilesInNewWindow also uses these values)
  • Both settings now default to default, which in most cases will reuse the last active window instead of opening a new one.

If configured to be default, VS Code still makes the best guess about reusing a window based on the context of the open request. Change the settings to either on or off if you want always want the same behavior. For example, if you always want a new window when picking a file or folder from the File menu, set this to on.

Note: There can still be cases where this setting is ignored (for example, when using the -new-window or -reuse-window command line option).

19.3.11 Control the dimensions of new windows

A new setting window.newWindowDimensions controls the size and positioning of new windows. By default, a new window will open in the center of the screen with small dimensions. If you change this setting to inherit, the new window will get the same dimensions as the last active one. Setting it to maximized or fullscreen will always open new windows maximized or in full screen.

19.3.12 Control menu visibility (Windows, Linux)

A new setting window.menuBarVisibility allows for more fine grained control over the top menu visibility on Windows and Linux. By default, the menu will be visible and only hides when entering full screen. You can set it to toggle to hide it. In the toggle state, the menu will show up when you press the kbstyle(Alt) key. If you turn the set the value to hidden, the menu will remain hidden, even if you press kbstyle(Alt).

Note: If you configure the menu explicitly to be visible, it will also remain visible when you enter the full screen mode.

19.3.13 Easy to close all editors when they are dirty

There are situations where you can end up with many dirty editors open (for example, you ran a search and replace operation without saving). Previously, when you wanted to close them all, you were asked to Save or Revert each editor one by one. Now, when you invoke the Close All Editors action (kb(workbench.action.closeAllEditors)), you will see a combined prompt for all dirty files:

Close All Prompt

19.3.14 Output scroll lock

Thanks to an external PR, it is now possible to easily stop output from automatically scrolling by toggling the scroll lock in the Output panel title bar.

Output scroll lock

19.4 Settings

In this milestone, we continued on the improvements we did for Settings during last milestone.

  • Improved search to match individual words with the setting’s key, value, allowed values and its description to yield better results.
  • Improved the layout of edit action to be more accessible, discoverable and consistent with other editor actions (Quick fix).
  • Improved the Settings editor UI by extending Search to both default (left) and configurable (right) settings. This brings you the benefit of searching across default and configurable settings.

19.4.1 User and Workspace Settings

  • Now you can quickly switch between User and Workspace settings from the single Settings editor. This helps users in discovering and understanding the user and workspace scopes.

Settings

19.4.2 Language specific settings

Our users often work on many different file types and languages in one workspace and a frequent feature request was language specific settings (#1587). With this release, you can now customize your editor by language through language based settings.

To customize for any language, run the global command Preferences: Configure language specific settings… (id: workbench.action.configureLanguageBasedSettings) from the Command Palette (kb(workbench.action.showCommands)) which opens the language picker. Selecting the language you want, opens the Settings editor with the language entry where you can add applicable settings.

Language mode for File

Language mode for File

Language mode for File

If you have a file open and you want to customize the editor for this file type, click on the Language Mode in the Status Bar to the bottom-right of the VS Code window. This opens the Language Mode picker with an option Configure ‘language_name’ language based settings…. Selecting this opens the Settings editor with the language entry where you can add applicable settings.

You can also configure language based settings by directly opening settings.json. You can scope them to the workspace by placing them in the Workspace settings just like other settings. If you have settings defined for a language in both user and workspace scopes, then they are merged by giving precedence to the ones defined in the workspace.

The following examples customize editor settings for language modes typescript and markdown.

{
  "[typescript]": {
    "editor.formatOnSave": true,
    "editor.formatOnPaste": true
  },
  "[markdown]": {
    "editor.formatOnSave": true,
    "editor.wrappingColumn": 0,
    "editor.renderWhitespace": "all",
    "editor.acceptSuggestionOnEnter": false
  }
}

You can use IntelliSense in Settings editor to help you find allowed language based settings. All editor settings and some non-editor settings are supported.

Note: The following settings are not currently supported but will be in the next release. Please refer to #19511 for more information.

editor.tabSize
editor.insertSpaces
editor.detectIndentation
editor.trimAutoWhitespace

19.5 Task support

19.5.1 Commands per task

You can now define different commands per task (#981). This allows running different commands for different tasks without writing your own shell script. A tasks.json file using commands per task looks like this:

{
    "version": "0.1.0",
    "tasks": [
        {
            "taskName": "tsc",
            "command": "tsc",
            "args": ["-w"],
            "isShellCommand": true,
            "isBackground": true,
            "problemMatcher": "$tsc-watch"
        },
        {
            "taskName": "build",
            "command": "gulp",
            "args": ["build"],
            "isShellCommand": true
        }
    ]
}

The first task start the TypeScript compiler in watch mode, the second one starts the gulp build. If a tasks specifies a local command to run the task name is not included into the command line (suppressTaskName is true for these tasks). Since a local command can specify local arguments, there is no need for adding it by default. Note that the tsc task specifies "isBackground": true. The property isWatching is deprecated in favor of isBackground to support more scenarios in the future.

If a tasks.json file specifies both global and task local commands, the task local commands win over the global command. There is no merging between a global and a task local command.

A task local command can be made OS specific as well. The syntax is the same as for global commands. Here an example that adds an OS specific argument to a command:

{
    "taskName": "build",
    "command": "gulp",
    "windows": {
        "args": ["build", "win32"]
    },
    "linux": {
        "args": ["build", "linux"]
    },
    "osx": {
        "args": ["build", "osx"]
    },
    "isShellCommand": true
}

As with global commands, the args and options property of the OS specific section are merged into the task command.

19.5.2 Task execution in Terminal

We implemented a new task execution engine that uses the terminal instead of the output window. This brings some major advantages:

  • ANSI control character support
  • Terminal input (a task can read input)
  • The platform character encoding is used by default
  • More than one task can be executed in parallel

The support is disabled by default, but early adopters can opt in to give feedback on the new implementation. To do so add the "_runner": "terminal" property to the top of your tasks.json file

{
    "version": "0.1.0",
    "_runner": "terminal",
    "tasks": [
        {
            "taskName": "tsc",
            "command": "tsc -w",
            "isShellCommand": true,
            "isBackground": true,
            "problemMatcher": "$tsc-watch",
            "isBuildCommand": true
        },
        {
            "taskName": "dir",
            "command": "dir",
            "isShellCommand": true
        }
    ]
}

Below a screen cast that first starts the tsc compiler in background (Using kb(workbench.action.tasks.build)) and then executes the dir command in another terminal.

Tasks in Terminal

There is one thing we changed for executing tasks in the terminal: if the task is a shell command arguments to the shell command should best be part of the command itself. The reason for this is proper quoting. With the old runner, it was always complicated to quote shell commands correctly especially under Linux/Mac shells where different kind of quotes exist (pre character escaping, weak quoting and strong quoting). If arguments are provided, we add them to the command without performing any quoting rules.

Please note that this is still work in progress. Feedback and suggestions are welcome.

19.6 Editor

19.6.1 Format on Paste

We have added a new setting to enable format on paste (#13945). Simply update your settings to include editor.formatOnPaste: true. Note that this works with existing formatters that support formatting a selection such as the TypeScript formatter or other formatters from the Marketplace.

19.6.2 Theme matching rules now respect TextMate semantics

Since our first version, VS Code has supported TextMate themes. There was, however one catch, we would leave it up to CSS to do token <-> theme rule matching. This was a great way to make progress at the time, but it also meant that TextMate themes were not rendered accurately in VS Code (for example, TextMate theme matching semantics are different than CSS class name matching semantics). The issues had been piling up and we decided it was time to improve our implementation (see issue #3008 for the rendering differences caused by this shortcut).

19.6.3 New Tools for inspecting TextMate Scopes

We have introduced a new widget to help inspect the scopes of a token and the matching theme rule. You can launch the widget with Developer Tools: Inspect TM Scopes from the Command Palette (kb(workbench.action.showCommands)).

Inspect TM Scopes

19.6.4 Insert snippets

You can now bind your favorite snippets to key bindings. A sample that encloses a selection with single quotes looks like this:

{
    "key": "cmd+k '",
    "command": "editor.action.insertSnippet",
    "args": { "snippet": "'$TM_SELECTED_TEXT'" }
}

Instead of defining a snippet with snippet, you can also refer to a snippet using the name-property, like { "name": "mySnippet" }

19.6.5 Go To Implementation

The new Go to Implementation and Peek Implementation commands allow you to quickly jump from an interface to its implementers, or from an abstract method to the method implementations. You can try out this feature by installing a nightly build of TypeScript 2.2 in your workspace: npm install typescript@next.

19.6.6 Persistent view options

Using Toggle Word Wrap, Toggle Render Whitespace and Toggle Control Characters will now persist the toggled value to user settings.

19.6.7 Match Case and Whole Words in multi-cursor actions

The multi-cursor actions always changed their behavior based on the toggle values for “Match Case” and “Whole Words”. However, this was not really obvious, especially when the Find widget is hidden. To make this more clear, triggering the following actions will now either highlight the toggles when the Find widget is visible, or briefly show the two options in the top right corner of the editor.

Here are the multi-cursor actions:

Label Default Key binding
Add Selection To Next Find Match kb(editor.action.addSelectionToNextFindMatch)
Move Last Selection To Next Find Match kb(editor.action.moveSelectionToNextFindMatch)
Add Selection To Previous Find Match kb(editor.action.addSelectionToPreviousFindMatch)
Move Last Selection To Previous Find Match kb(editor.action.moveSelectionToPreviousFindMatch)
Select All Occurrences of Find Match kb(editor.action.selectAllMatches)
Change All Occurrences kb(editor.action.changeAll)

Moreover, the two options will briefly show in the top right corner of the editor also when toggling their value via Toggle Find case sensitive (kb(toggleFindCaseSensitive)) or Toggle Find whole word (kb(toggleFindWholeWord))

19.6.8 Find widget, \n and CRLF files

The semantics of \n in the find widget search string, when in regex mode, has now changed to always match the End-Of-Line sequence.

Whereas before, \n would always match the \n character, \n will now match the \n characters in files with \n line terminators (indicated in the Status Bar with LF) and will match the \r\n sequence in files with \r\n line terminators (indicated in the Status Bar with CRLF).

19.6.9 Indentation rules improvements

We polished our implementation of Indentation Rules, which Language extensions can leverage to determine the correct indentation level for a specific line. The indentation adjustments are usually triggered after users finish writing a line and press kbstyle(Enter).

In addition, we implemented an experimental command Reindent Lines and you can use it to adjust the indentation of the whole file if the indentation rules are properly set.

19.7 Languages

19.7.1 TypeScript references CodeLens

The TypeScript references CodeLens displays an inline count of reference for classes, interfaces, methods, properties, and exported objects:

TypeScript references codelens

You can enable the TypeScript references CodeLens by setting "typescript.referencesCodeLens.enabled": true.

Click on the reference count to quickly browse a list of references:

TypeScript references codelens peek

19.7.2 TypeScript

VS Code now includes TypeScript 2.1.5, which includes a number of important bug fixes.

19.7.3 TypeScript Version Configuration

You can now more easily switch which version of TypeScript is being used in your workspace by opening a TypeScript or JavaScript file in the workspace and clicking on the TypeScript version number in the status bar:

TypeScript status bar version

A message box will appear asking you which version of TypeScript VS Code should use:

TypeScript version selector

After switching TypeScript versions, reload the VS Code window to apply the change.

Due to a potential security issue, VS Code will no longer automatically load versions of TypeScript from a typescript.tsdk workspace setting. When a workspace with a typescript.tsdk workspace setting is loaded for the first time, we ask you if we should use the workspace version of TypeScript or VS Code’s version.

19.7.4 Markdown Preview and editor integration

VS Code can now synchronize the view of a Markdown editor and its preview (#6992). By default, the Markdown preview will automatically scroll to reveal the element at the selected line in the editor.

Markdown Preview editor selection scroll sync

Also, when the Markdown preview is scrolled, the editor will scroll along with it:

Markdown Preview to editor scroll sync

Additionally, you can now double click an element in the Markdown preview to automatically open the editor at that line:

Markdown Preview double click switches to editor

19.7.5 Other Markdown improvements

  • Syntax highlighting for C++, Go, Rust, and Scala code blocks in Markdown files.
  • Fixed Markdown syntax highlighting for block elements on a line immediately after a paragraph.
  • When the Markdown preview is first opened, it will automatically scroll to the selected line in the editor.
  • A gray bar in the left margin of the Markdown preview indicates the currently selected line.
  • Links to local files now work in the Markdown preview.
  • In the Markdown editor, you can kbstyle(Ctrl) click on links to local files to open them in the editor.

19.7.6 Load Emmet preferences, profiles, snippets and abbreviations from external files

The new setting emmet.extensionsPath can be used to provide a location (absolute path or relative to workspace) where any or all of snippets.json, syntaxProfiles.json and preferences.json reside. Read more about how to customize Emmet using these files at Emmet Customization.

The existing settings emmet.preferences and emmet.syntaxProfiles will override the values from the above json files.

Note: The file contents are cached. Therefore, you will need to reload the VS Code window the first time you add these files and every time you modify them.

19.7.7 SCSS map support

The SCSS language support now also understands the SCSS map syntax (#1758).

19.7.8 New HTML settings

The HTML formatter (based on the jsbeautifier) has been updated. New options are available:

  • html.format.contentUnformatted: List of tags, comma separated, where the content shouldn’t be reformatted. null defaults to the pre tag
  • html.format.wrapAttributes: Wrapping strategy for attributes:
  • auto: Wrap when the line length is exceeded
  • force: Wrap all attributes, except first
  • force-aligned: Wrap all attributes, except first, and align attributes
  • force-expand-multiline: Wrap all attributes

The following options allows to disable of script and style validation:

  • html.validate.scripts: Configures if the built-in HTML language support validates embedded scripts.
  • html.validate.styles: Configures if the built-in HTML language support validates embedded styles.

19.7.9 New PHP settings

The following options allows to disable the built-in PHP completion and hover supports:

  • php.suggest.basic: Configures if the built-in PHP language suggestions are enabled. The support suggests PHP globals and variables.

19.7.10 Confirmation of the php.validate.executablePath setting

Due to potential security risks, VS Code asks for confirmation of the php.validate.executablePath workspace setting before executing the program the setting is pointing to.

Confirming PHP executable

If the path is set in user settings, no confirmation is necessary.

19.8 Extensions

19.8.1 Easily create an Extension Pack

Extension Packs allow you to bundle separate extensions together so that they can be installed together. We have added support to create an Extension Pack using the Code Yeoman generator.

extensionpackgenerator

The generator creates an Extension Pack extension. Optionally, it can also seed the pack with the set of extensions you have currently installed in your Code instance. In this way you can easily create an Extension Pack with your favorite extensions, publish it to the market place, and share it with others.

19.9 Debugging

19.9.1 Debugging without a launch configuration

As per popular user request, we no longer require a launch.json file to start debugging - simply pressing kb(workbench.action.debug.start) will immediately start the debug session. This makes it possible to debug single files (in a so called ‘no-folder-workspace’ indicated by a purple colored Status Bar). A launch.json is still required for advanced debug configuration.

Note: This feature is currently supported only by the Node.js and PowerShell debuggers but will be picked up soon by other debug extensions.

no folder debug

19.9.2 Inline variable values in source code

Thanks to a user PR we are now able to show variable values inline in the source while stepping through the code.
This feature is still experimental, so it is disabled by default. To enable it set "debug.inlineValues": true in your settings.

debug inline values

19.9.3 Automatically choosing debug environment

Depending on the active file, VS Code can now automatically choose a debug environment instead of explicitly asking the user. For example, if a user has a JavaScript file active in an editor and wants to setup his launch.json, a launch.json for JavaScript is automatically generated.

19.9.4 User level launch.json

As per user request, it is now possible to have a “launch” object in your user settings that is shared across all the workspaces as a launch configuration.

19.9.5 Add launch configuration from dropdown

It is now possible to add a new launch configuration by simply choosing that option in the debug dropdown:

add launch configuration

19.9.6 Copy callstack action

We have added a context menu action in the callstack view that copies the callstack to the clipboard. This can be very handy when you need to report a callstack with an issue.

debug inline values

19.10 Node Debugging

19.10.1 Launch configuration snippets for Node scenarios

We’ve added a few launch configuration snippets to support some commonly used Node.js debugging scenarios. These snippets can be used through IntelliSense when editing the launch.json:

Launch configuration snippets for node.js

Here is the list of all snippets:

  • Launch Program: Launch a node.js program in debug mode. The snippet asks you to enter the name of the program file.
  • Launch via NPM: Launch a node program through an npm ‘debug’ script. If you have defined an npm debug script in your package.json, you can use this directly from your launch configuration. Make sure that the debug port used in the npm script, corresponds to the port specified in the snippet.
  • Attach to Port: Attach to the debug port of a running Node.js program. Make sure that the Node.js program to debug has been started in debug mode and the debug port used is the same as the one specified in the snippet.
  • Attach to Process: Open the process picker to select a node or gulp process for debugging. With this launch configuration you can even attach to a node or gulp process that was not started in debug mode.
  • Nodemon Setup: Use nodemon to relaunch a debug session automatically whenever the JavaScript source has changed. Make sure that you have nodemon installed globally. Please note that terminating the debug session only terminates the program to debug, not nodemon itself. To terminate nodemon, press Control-C in the integrated terminal.
  • Mocha Tests: Debug mocha tests in a test folder of your project. Make sure that your project has ‘mocha’ installed in its node_modules folder.
  • Yeoman generator: Debug a yeoman generator. The snippet asks you to specify the name of the generator. Make sure that your project has ‘yo’ installed in its node_modules folder and that your generated project has been installed for debugging by running npm link in the project folder.
  • Gulp task: Debug a gulp task. The snippet asks you to specify the name of the gulp task. Make sure that your project has ‘gulp’ installed in its node_modules folder.

19.10.2 Just My Code improvements

We’ve added some finishing touches to the ‘Just My Code’ feature introduced in the last milestone:

  • Support for skipping core modules with the skipFiles attribute. It is now possible to use the ‘magic name’ <node_internals> in a glob pattern to refer to the core modules built into Node.js.

The following example skips all internal modules but events.js:

json "skipFiles": [ "<node_internals>/**/*.js", "!<node_internals>/events.js" ]

  • Skipped source is now shown in a ‘dimmed’ style in the CALL STACK view:

Skipped source is dimmed in call stack view

Hovering over the dimmed entries explains why the stack frame is dimmed.

  • Context menu action for skipping additional source files at runtime (node2 only):

toggle skip files

A new context menu item on the call stack, Toggle skipping this file enables you to easily skip a file at runtime without adding it to your launch config. This option only persists for the current debugging session. You can also use it to stop skipping a file that is skipped by the skipFiles option in your launch config.

19.10.3 Support ‘restart’ option for ‘launch’ requests

For quite some time the VS Code node debugger supported a restart attribute on attach configurations. See here for details. With this release, we now support the restart attribute on launch configurations as well.

If this feature is enabled, VS Code restarts a debug session whenever it detects the termination of Node.js. This feature can be used in combination with the nodemon utility which restarts Node.js whenever it detects that JavaScript source has been modified.

This launch configuration (available as a snippet through IntelliSense) makes use of nodemon and the restart option:

{
    "type": "node",
    "request": "launch",
    "name": "nodemon",
    "cwd": "${workspaceRoot}",
    "runtimeExecutable": "nodemon",
    "runtimeArgs": [
        "--debug=5858"
    ],
    "program": "${workspaceRoot}/app.js",
    "restart": true,
    "port": 5858
}

19.10.4 Source map support now always enabled

Starting with this release, source map support is enabled by default, so it is no longer necessary to set sourceMaps to true. However, it is still necessary to let the Node.js debugger know where the generated JavaScript lives by specifying the outFiles glob patterns. Source map support can be disabled by setting sourceMaps to false.

19.10.5 Better object display in the console (node2)

In the node2 debug adapter, calling console.log with an object will now show an expandable object in the console, instead of a text preview.

log objects

19.11 Extension Authoring

19.11.1 Editor API to insert a snippet

There is a new TextEditor#insertSnippet method that allows you to insert a SnippetString into an editor.

19.11.2 Updating CodeLens

A CodeLensProvider can now have a onDidChangeCodeLenses-event which signals to the editor that lenses have changed and need to be refreshed.

19.11.3 Completion item commit characters

CompletionItems can now have a list of commit characters. When a commit character is typed and while a completion is selected, the completion will be inserted as the character is being typed.

19.11.4 Added new ImplementationProvider API

A new ImplementationProvider interface was added to support the new Go to Implementation feature. A ImplementationProvider maps a location in a text document to a list of implementations locations, for example going from an interface to classes that implement this interface or from an abstract method to a list of implementing methods.

Extensions that wish to support Go to Implementation can implement ImplementationProvider and register the provider using vscode.languages.registerImplementationProvider

19.11.5 New API to open an untitled file with optional language

A new overload was added to the openTextDocument method that allows to open an untitled document with optional language. For example you can call:

openTextDocument({ language: 'xml' })

To create a text document with XML as language. If you leave out the language options, it will just create a text document with plain text language.

19.11.6 TextEditorRevealType.AtTop

A new AtTop value was added to the TextEditorRevealType enum. This reveals the range at the top of the viewport.

19.11.7 CompletionItemKind.Folder

A new Folder value was added to the CompletionItemKind enum.

19.11.8 Proposed Progress API

We have a proposed API to show progress in different places of the editor, such as the Status Bar or a view. It is still in its early stages and we are looking for feedback. To try it out, do the following:

  • Copy vscode.proposed.d.ts into your TypeScript project.
  • In the package.json of your extension, add "enableProposedApi": true to enable the proposed APIs.

Note that proposed APIs are only available when developing an extension but not when an extension is published to the Marketplace.

19.11.9 Contributable SCM Providers

We started large refactorings around source control in order to provide SCM functionality from different contributable providers. At the same time, all Git functionality is being ported over to an SCM provider.

The new behavior is available for you to try out with via the SCM: Enable Preview SCM command, which will replace the current Git functionality with the experimental one (run SCM: Disable Preview SCM to undo). Be aware that this is not feature complete nor without issues. You can track progress in #18615.

19.11.10 Debugger Extension Authoring

We’ve added the following (optional) sub-contribution points to the debuggers contribution point:

  • languages<BR>Here those languages can be listed for which the debug extension could be considered the “default debugger”. VS Code makes use of this information only in cases where a debugger must be found automatically for a given source language.

  • startSessionCommand<BR>takes the ID of a command which VS Code calls for any “debug” or “run” action targeted for this extension. If a launch configuration was selected, it is passed as an argument to the command (and the extension can massage the launch config as desired). If “debug” or “run” is executed without an existing launch config, an empty launch config is passed to the startSessionCommand and the extension is expected to “fill in” missing attributes e.g. based on the file currently open in the editor.

  • adapterExecutableCommand<BR>VS Code launches a debug adapter by using the (static) attributes program, args, runtime and runtimeArgs from the package.json of the corresponding extension. Starting with this milestone an extension can alternatively contribute a command where the debug adapters executable path and arguments are dynamically calculated.<BR>Instead of defining the attributes program, args, runtime and runtimeArgs on a debuggers contribution in the package.json, set a new attribute adapterExecutableCommand to the ID of a command that is registered in the extension. Make this command return a structure with this format:
    json command: "<executable>", args: [ "<argument1>", "<argument2>", ... ]
    The attribute command must be a either an absolute path to an executable or a name of executable looked up via the PATH environment variable. The special value node will be mapped to VS Code’s built-in node runtime without being looked up on the PATH.

19.11.11 VS Code Debug Protocol

A new optional attribute presentationHint has been added to the Source type. With this a debug adapter can provide a hint for how to render a source in the UI. A value of deemphasize can be used to indicate that the source is not available or that it is skipped on stepping.

19.12 Miscellaneous

19.12.1 Settings and security

In settings, we allow you to specify some of the executables that VS Code uses to do its work. For example, you can choose which shell the Integrated Terminal should use. Until now, just like any other setting, you could define them either as user settings or workspace settings. For enhanced security, we no longer allow such settings to be defined at the workspace level.

Here is the complete list of settings we no longer support at the workspace level:

  • git.path
  • terminal.integrated.shell.linux
  • terminal.integrated.shellArgs.linux
  • terminal.integrated.shell.osx
  • terminal.integrated.shellArgs.osx
  • terminal.integrated.shell.windows
  • terminal.integrated.shellArgs.windows
  • terminal.external.windowsExec
  • terminal.external.osxExec
  • terminal.external.linuxExec

When you open a workspace and we find for the first time that the workspace defines any of these settings, VS Code will warn you and subsequently ignore the values.

The typescript.tsdk and php.validate.executablePath setting created a similar security exposure which has been addressed separately.

19.12.2 Launch new instance from Unity on Ubuntu

The standard shortcuts to launch a new instance of an application from the Ubuntu Unity user interface now correctly open a new instance of VS Code (kbstyle(Win+Shift+<number>), kbstyle(Shift)+click, middle click).

19.12.3 New command to report performance issues

We added a new command, Report Performance Issues in the Command Palette, that makes it very easy to open a new GitHub issue with details about your environment and performance timings prefilled into the issue description (OS, CPUs, Memory, task timings). If you think that VS Code is starting slow on your system, please use this new command to tell us about it!

19.12.4 Editor Performance Optimization

We have added a heuristic that reduces the time taken to paint a frame in the editor significantly in certain conditions (that occur more than 95% of the time).

If the font you are using is monospace (most of the programming fonts are monospace), if a certain line consists only of ASCII characters (most of the lines in source code stick to the ASCII range 32-126 or tabs), and if certain editor decorations (like the color boxes in CSS) are not present on a line, we can skip interrogating the browser about where the text has ended up painted and simply do the math in JavaScript.

This optimization saves us a forced browser layout and further decreases the time it takes us to paint a frame.

Note: If you notice the cursor being rendered slightly off from the text, please let us know. You can disable this optimization via editor.disableMonospaceOptimizations.

19.13 Notable Changes

  • 16803: Preserve language picked for untitled text documents
  • 16588: Preserve view state for untitled files between restarts
  • 17408: Search does not work in UTF-16 LE encoded files
  • 12831: Support standard tab navigation key shortcuts on macOS
  • 10444: Persist character encoding of open files across restart
  • 18037: Possible to save file multiple times leads to race condition
  • 14464: Preserve editor relative sizes when switching layouts
  • 18003: Search relevance in Quick Pick control
  • 14625: Update menu when reassigning keybindings or installing keybinding extension
  • 18290: Moving or renaming file does not preserve editor view state
  • 12040: Identical file name path in tab is too long and difficult to diff
  • 17495: Explorer: Does not sort files and folders with numerical values accordingly
  • 7876: Allow to use Ctrl P/N for up and down navigation in quick open
  • 6502: Apply excludes to editor history quick open too
  • 18679: F4 added as a keybinding to navigate search results - may conflict with some extension keybindings
  • 11908: ALT + Arrows does not work in integrated terminal
  • 14479: Integrated Terminal eats half of the first line when you zoom
  • 18952: Terminal tab stops broken after resize
  • 18332: Background terminal scroll bars are not synced when the foreground terminal is resized
  • 18758: Hard crash (of everything) when debugging nodejs
  • 19377: Explorer refresh not working for folders with same prefix

These are the closed bugs and these are the closed feature requests for the 1.9 update.

19.14 Contributions to Extensions

Our team maintains or contributes to a number of VS Code extensions. Most notably:

In addition, we released an early-stage PHP parser designed for IDE usage scenarios. This will help extension authors provide even better tooling support for PHP. The parser is written in PHP, and is built to be fast and memory-efficient, provide graceful error-handling, and produce fully-representative syntax trees (including comments/whitespace).

19.15 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-eslint:

Contributions to vscode-tslint:

Contributions to vscode-languageserver-node:

Contributions to language-server-protocol:

Contributions to vsce:

Contributions to vscode-generator-code:

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

20 April 2016 (1.1)

The April 1.1 release is our first monthly release after announcing 1.0. We have been overwhelmed by the positive response to that release and the excitement in the community for VS Code and the rapidly growing ecosystem of new languages and extensions.

Keeping to our monthly release cadence, we’ve put together a nice selection of new features and fixes in April. We hope you enjoy it.

Here is an overview of some of the updates contained in this release:

  • Quickly resize panes by double-clicking editor borders
  • Reopen the last closed file using kb(workbench.action.reopenClosedEditor)
  • Launch your favorite shell when opening a new Terminal from the Explorer or Command Palette

Extension authors will be especially happy with these updates:

  • Language Server protocol 2.0 is now consistent with core VS Code API
  • Automated test support for authoring Debug Adapters
  • New APIs for working with folders and JSON files

Downloads: Windows |
OS X | Linux 64-bit .zip .deb .rpm | Linux 32-bit .zip .deb .rpm

20.1 Editor

20.1.1 Visual design for editor tabs

We have a visual design for how editor tabs might look in VS Code. We will start to implement the design in the next milestone.

20.1.2 Disable automatic revealing of files in the explorer

By default, VS Code expands folders and scrolls your active file into view in the file Explorer. If you don’t want this automatic reveal behavior, you can disable it through a new setting explorer.autoReveal. Set explorer.autoReveal to false to prevent your Explorer view from changing as you switch between active files. There is a new action, Show Active File in Explorer, if you would like to explicitly display (reveal) the currently active file in the Explorer.

20.1.3 Resize border (sash) double clicks

You can now double-click on some resize borders (sashes) in the workbench to quickly resize them:

  • Double click on the Explorer resize border to size the sidebar to show file paths without being trimmed.
  • Double clicking the resize border of other Views (Search, Git, Debug) will cause the sidebar to shrink to its minimum width.
  • If you have multiple editors open, double clicking the resize border between them will resize the open editors to equal width.
  • Double clicking the resize border of the side by side diff editor will resize the diffs to equal width.
  • Double clicking the resize border of the lower OUTPUT/DEBUG CONSOLE panel will resize the panel to its minimum height.

20.1.4 Reopen closed file command

The workbench.action.reopenClosedEditor command has been added which will reopen the most recent file removed from the working files list. The default key binding for this command is kb(workbench.action.reopenClosedEditor).

Note: Previously kb(workbench.action.reopenClosedEditor) had been bound to the Run: Run Test Task command. Run: Run Test Task is now not bound to any default key binding. You can customize the key bindings and change the behavior back to the previous one if desired.

20.1.5 Disable Emmet abbreviation expansion on Tab

You can now disable the Emmet abbreviation triggered on kbstyle(Tab) using the emmet.triggerExpansionOnTab setting.

20.2 Debugging

20.2.1 Call Stack Paging

VS Code debugging now supports arbitrarily deep call stacks. For performance reasons, we only load twenty frames initially but there is now a button at the bottom for loading the next set of frames:

Load More Stack Frames button

20.2.2 Improved thread support

Debugging multi-threaded programs has been improved. The currently debugged thread is now automatically expanded and several issues were fixed to make debugging multiple threads a smoother experience.

20.3 Node.js Debugging

20.3.1 Support for ES6 Sets, Maps, and Generators

The VS Code Node.js debugger no longer shows ES6 Sets, Maps, Promises, and Generators as undefined or empty objects.

Set and map items show a sequence number next to the item because both data structures preserve the insertion order:

ES6 set with sequence number

ES6 map with sequence number

Generators show its state:

Show ES6 generator state

20.3.2 Support for property getters

Object properties with getters are no longer shown as undefined. An example for this are the environment variables available through process.env.

20.3.3 String truncation limit lifted

The Node.js V8 debugger protocol truncates strings automatically to a (non-configurable) 80 characters. In the April release, VS Code works around this limitation and truncates only strings with more than 10000 characters.

20.3.4 Improved performance with large data structures in Node.js 4.x, 5.x

Inspecting large data structures like arrays or buffers results in Node.js becoming unresponsive because the V8 debugger protocol does not provide a way to access large data structures in chunks. In Node.js 0.12.x, VS Code started to dynamically inject code into the Node.js runtime to improve the V8 debugging protocol but this stopped working after the io.js/node.js reunion for 2.x and 3.x versions. A recent fix to Node.js made code injection work again. So if you see performance problems, make sure that you are using at least Node.js version 4.3.1 of the LTS stream or version 5.6 of the stable stream.

20.3.5 Smart code stepping

We added experimental support for automatically skipping ‘uninteresting code’ when stepping through code in the debugger. ‘Uninteresting code’ is code that is generated by a transpiling process but is not covered by a source map so it does not map back to the original source. This code gets into your way when stepping through source code in the debugger because it makes the debugger switch between the original source code and generated code that you are not really interested in.

This experimental feature automatically steps through code not covered by a source map until it reaches a location that is covered by a source map again. To enable the feature, just add the attribute smartStep with a value of true to your launch configuration.

The following screen cast shows stepping through a simple async/await snippet first with the feature disabled and then enabled:

skipping code with smartStep

20.4 Setup

20.4.1 Portability improvements on Linux

The zip archive now included the CLI (./bin/code) and has been improved to support custom install locations and work when symlinked to.

20.4.2 Launch your preferred shell

You can now specify which external shell VS Code will launch when you use commands like Open in Command Prompt (or Open in Terminal on OS X or Linux). Set the terminal.external user or workspace setting for your platform (windowsExec, linuxExec) to the executable to launch (cmd is the default for Windows).

For example, to set PowerShell as your external shell on Windows and Terminator on Linux, use:

{
    "terminal.external.windowsExec": "powershell",
    "terminal.external.linuxExec": "terminator"
}

OS X support has not been implemented yet (#5462).

20.5 Extension Authoring

20.5.1 New command to open a folder in the same or new window

We added a new command for extension writers to open a folder in the same or new window. The command identifier is vscode.openFolder and it accepts two optional arguments uri and newWindow. If you omit the uri argument, the native file dialog is displayed for the user to select a folder.

20.5.2 Custom Close action when showing messages

The extensions API now allows you to provide custom Close button affordance (text and action) when showing a message using window.show{Information|Warning|Error}Message call. Just pass in a message item which has the isCloseAffordance-property set to true.

When previewing HTML files with the vscode.previewHtml command, links are now interpreted in the context of VS Code. That is file-links are resolved within the editor, web-links with the default browser. Also commands are supported using the command-scheme. For instance, command:vscode.previewHtml?["file:///some/file.html"] tells the editor to run the command vscode.previewHtml using arguments that are JSON-encoded as query.

20.5.4 Enhance support for your JSON configuration files

If you have your own JSON files and want to improve the editing experience, you can associate JSON schemas to your files. The schemas associations will be picked up by the JSON language support that ships with VS Code and you will get validations, completions and hovers for free. The schema association can be done either by a user configuration or by an extension point.

In some cases, you want more control, for example, you may want to provide completion support that requires a database lookup, or you want validation that cannot be expressed by a regular expression. To implement your own completion, validation, and hover support, you can use the regular VS Code APIs. To make this easier, we moved our JSON scanner and parsers to a node-module, jsonc-parser, that you can reuse. You can see this module in action with the dependency completion support for package.json and bower.json that is now part of the JavaScript extension and for project.json soon to be part of the C# extension.

20.5.5 ‘onDebug’ Activation Event

Upon starting a debug session, VS Code now emits a onDebug:{type} event, for example ‘onDebug:node’. Debug extensions can now be activated by listening for this activation event.

20.6 Debug Adapter Development

For Node.js based debug adapter development, we’ve made the debug adapter test support available as an npm module vscode-debugadapter-testsupport.

The source for this module lives in the GitHub repository vscode-debugadapter-node.

You can find examples of how to use the module here:

20.7 Electron Shell

We updated the Electron shell to 0.37.6.

20.8 Language Server Protocol

Version 2.x of the language server protocol was released together with a corresponding client library to be used in extensions and a server library for Node.js.

The major changes are:

  • Alignment of the protocol with the VS Code extension API.
  • Consistent support for language identifiers. This means that the language ID is passed to the server via the open notification.
  • Support for version numbers on documents.
  • Text document save notifications.
  • Support for request cancellation.

20.9 Bug Fixes

This release has a number of notable bug fixes.

  • 3928: VS Code corrupts multi-line environment variables
  • 4426: Include CLI in Linux zip archive and support custom install locations
  • 4478: “Open in Terminal” not working on Fedora
  • 4691: Command palette’s camel case matching does not work for non ASCII characters
  • 4679: Don’t localize command names on the command palette
  • 5260: Use proper font family for East Asian languages (CJK)
  • 4400: Add update notifications for Linux
  • 1796: HTTPS Authentication not working on Linux
  • 6281: Edits fail to validate ranges correctly before applying
  • 6304: Debug: continue action is broken when target app has multiple threads

These are the closed bugs and these are the closed feature requests for the 1.1.0 update.

20.10 Thank You

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

21 December 2015 (0.10.6)

Hi,

November was a big release for us (adding extensibility support and moving to open source) and we appreciate all the support we received leading up to and during the Connect(); event. We’ve kept busy in December and we hope you like this release.

These release notes only capture what’s new in the core of Visual Studio Code. Do not forget to check out the marketplace for new extensions.

Downloads: Windows | OS X | Linux 32-bit | Linux 64-bit

21.1 Thanks

A big thanks for the great contributions we have received. The community has filed over 200 bugs, 280 feature requests, and submitted 70 pull requests. We have addressed many of these issues and merged most of the pull requests.

These are the closed bugs and these are the closed feature requests for the December milestone.

Regarding fixes, if you want to find out when a fix to your issue is available in a VS Code update, please check the milestone assigned to the issue.

21.2 Insider’s Channel

There is now a setting to subscribe to the Insider’s channel to get prerelease VS Code builds automatically. The setting is update.channel and it defaults to stable which is the current release build. Change the value to insiders and restart VS Code to install prerelease builds. For more details, refer to How can I test prerelease versions of VS Code?.

21.3 Editor - Find/Replace improvements

In regex mode:

Keyboard shortcuts:

  • New Find settings commands: toggle case-sensitive (kb(toggleFindCaseSensitive)), toggle regex (kb(toggleFindRegex)) and toggle whole word (kb(toggleFindWholeWord))
  • kb(actions.find) puts focus in the Find input field.
  • kb(editor.action.startFindReplaceAction) puts focus in the Replace input field.
  • When focus is in the Find widget input fields, kbstyle(Ctrl+Down) put focus in the editor.

21.4 Changed defaults and key bindings

  • Changed the defaults for editor.insertSpaces to true and editor.tabSize to 4. To get the previous behavior, you can change both settings back to "auto".
  • Changed the default key bindings on Linux for Insert Cursor Below (kb(editor.action.insertCursorBelow)), Insert Cursor Above (kb(editor.action.insertCursorAbove)), Move Line Down (kb(editor.action.moveLinesDownAction)) and Move Line Up (kb(editor.action.moveLinesUpAction))

21.5 Editor - Cursor Blinking Options

New setting to configure cursor blinking: editor.cursorBlinking with values blink, visible and hidden thanks to community contribution.

21.6 Editor - Select Current Line Command

New select current line command (kb(expandLineSelection)) thanks to a community contribution.

21.7 Editor - Scroll Viewport Commands

Thanks to a community contribution, VS Code has improved editor scroll support:

  • Scroll by one line up (kb(scrollLineUp)) / down (kb(scrollLineDown))
  • Scroll by one page up (kb(scrollPageUp)) / down (kb(scrollPageDown))

21.8 Key Bindings for Numeric Keypad

Added support for function keys kbstyle(f13-f19) and for the numeric keypad keys:

  • kbstyle(numpad0-numpad9)
  • kbstyle(numpad_multiply)
  • kbstyle(numpad_add)
  • kbstyle(numpad_separator)
  • kbstyle(numpad_subtract)
  • kbstyle(numpad_decimal)
  • kbstyle(numpad_divide)

21.9 Improvements for non US standard keyboard layouts

VS Code dispatches key bindings based on keyboard codes. In keybindings.json and in all the UI, we used to render the key codes with the produced characters under the US standard keyboard layout. We received feedback that this was very confusing, therefore, we created a new Node.js module native-keymap that is used in VS Code to render the key bindings using the system’s current keyboard layout.

For example, Split Editor when using a French (France) keyboard layout is now rendered as kbstyle(Ctrl+*):
render key binding

When editing keybindings.json, we now highlight misleading key bindings - those that are represented in the file with the character produced under the standard US keyboard layout, but which need pressing keys with different labels under the current system’s keyboard layout.

For example, here is how the Default keybindings rules look like when using a French (France) keyboard layout:

keybindings.json guidance

Finally, we added a new widget that helps input the key binding rule when editing keybindings.json. To launch the Define Keybinding widget, press kb(editor.action.defineKeybinding). The widget listens for key presses and renders the serialized JSON representation in the text box and below it, the keys that VS Code has detected under your current keyboard layout. Once you’ve typed the key combination you want you can press kbstyle(Enter) and a rule snippet will be inserted.

key binding widget

21.10 ES6 is the new default

We have made ES6 the default for JavaScript files. This means you don’t need to create jsconfig.json files to enable new syntax and by default you get suggestions for ES6-types, like Promise, Set, Map, String.startsWith and much more. Thanks to a community contribution.

At the same time, the grammar used to colorize JavaScript was also updated to support the ES6 syntax.

21.11 TypeScript Update

The TypeScript language service was updated to version 1.7.5.

21.12 JSX Support

To improve the JavaScript and JSX support, the plan is to adopt Salsa. There is good progress on the Salsa project, but until VS Code has switched over to Salsa, we can only offer a workaround for using VS Code with JSX.

  • Install the vscode-eslint extension and configure JSX support. This will provide you with validation in JSX files.
{
    "ecmaFeatures": {
        "jsx": true,
        ...
    }
    ...
}
  • If you are using React constructs inside .js files then you can install the js-is-jsx extension which changes the file mapping so that .js files are treated as .jsx files. Be aware that if you install this extension, you lose the existing language support for .js files.

The grammars used to colorize JS and JSX are now aligned.

21.13 Extension Debugging

We improved extension debugging when connecting the debugger to the extension. The debugger will no longer try to reconnect to the extension when you close the ’Extension Host`. In addition, the debugger will connect faster to your extension.

21.14 Extensions Show Outdated Extensions

Thanks to a community contribution, there is now a Show Outdated Extensions command, that shows all outdated extensions and lets you quickly install their updates.

21.15 Installed Extension Issues

If VS Code identifies an issue with an installed extension, it will display an issues prompt on the Status Bar. Click on the issues prompt to see the extension issue details and have the option to uninstall the extension.

extension issues

There is now proxy support for the extension gallery.

21.17 Extension Deactivation

If an extension exports a function named deactivate(), VS Code now calls it on shutdown.

The file picker (“Quick Open”) is now able to search on file paths when you include slash (Mac/Linux) or backslash (Windows) in the search term. This allows you to list all the files of a directory easily.

Path Search in File Picker

A new setting filePicker.alternateFileNameMatching enables fuzzy searching for the file picker. Once enabled, the search term will match on the full path of the file by default, without having to include path separators in the query. In addition, a search term will match in a more fuzzy way on the path compared to the default. For example, a search for fb will match a file foobar because the filename contains f and b. We also added a new sorter for the picker when fuzzy searching is enabled which tries to put the most relevant results to the top. Please try out this feature and give us feedback so that we can tune the experience.

Fuzzy Search in File Picker

21.19 Persisted Zoom Level

A new setting window.zoomLevel allows you to change and persist the zoom level of the window. The default value is 0 and each increment increases the zoom level by 20% similar to the effect of the View menu Zoom in command. Unlike the zoom level set with the Zoom in and Zoom out commands, the window.zoomLevel is a setting persisted across VS Code sessions.

21.20 window.openFileInNewWindow

The setting window.openInNewWindow was renamed to window.openFilesInNewWindow to clarify its purpose. You can still use the old setting but we ask you to update to the new name.

21.21 Themes

Various fixes to the default light and dark theme. Due to the move to TextMate tokenizers in the last release, there were changes in the appearance of the default light and dark theme. Some themes got far more colorful, in particular JavaScript, while other languages lost colors, e.g. Jade and XML. The goal was to stay as close as possible to what we had in the 0.9.0 release so we use a few major colors: blue for keywords, green for comments and red for strings.

21.22 Emmet

Emmet is now supported in JSX and TSX files.

21.23 Scoped Git Services

It is now possible to open a sub-directory of a Git repository in VS Code. VS Code’s Git services will still work as usual, showing all changes within the repository, but file changes outside of the scoped directory are shaded and have a tool tip indicating the file is located outside the current workspace.

21.24 Git Status Bar Actions

There is now a Synchronize action in the Status Bar, next to the branch indicator, when the current checked out branch has an upstream branch configured.

git status bar sync

If there is no upstream branch configured and the Git repository has remotes set up, a new Publish action is enabled. This will let you publish the current branch to remote.

git status bar publish

21.25 Debug Console Wraps Text

We now wrap long text in the debug console.

debug console word wrap

21.26 Debug Breakpoints Polish

We now show breakpoints in a more intuitive way:

  • A red filled circle represents an active breakpoint.
  • A gray filled circle represents a disabled breakpoint.
  • A gray hollow circle represents a breakpoint which could not be successfully registered with the debugger. For languages that are transpiled to JavaScript, this could mean that source maps are missing or invalid.

21.27 JSON Schema Contributions

Extensions can now contribute JSON schema associations. The jsonValidation contribution point takes a file pattern and the URL of the JSON schema.

    "contributes": {
        "jsonValidation": [{
            "fileMatch": ".jshintrc",
            "url": "http://json.schemastore.org/jshintrc"
        }]
    }

Alternatively, extensions can also give the path to a schema file in the extension folder:

    "contributes": {
        "jsonValidation": [{
            "fileMatch": ".htmlhintrc",
            "url": "./schemas/htmlhintrc.schema.json"
        }]
    }

21.28 Language Server Extensions

The language server protocol now supports all available language features. Please see the Language Server example for details on how to implement a language server.

21.29 Debug Adapter Development

For Node.js based debug adapter development, we’ve made the VS Code Debug Protocol and an adapter default implementation available as npm modules:

The source for these modules lives in the GitHub repository vscode-debugadapter-node. Both mock-debug and node-debug have been updated to use the npm modules.

21.30 Engineering

The VS Code GitHub repository supports continued integration for branches and pull requests:

During this first iteration of VS Code being open source, we tuned and documented more of our development workflows:

We updated Electron to version 0.34.5. This includes a bug fix for the issue on Linux where the editor font was showing blurry on certain high DPI displays.

21.31 Notable Bug Fixes

21.32 What’s next

The VS Code development team will now take time off to be with friends and family. We will be back fully recharged in January.

22 February 2016 (0.10.11)

February is our last full iteration before we start the end game for the Build 2016 conference milestone at the end of March. It comes with many improvements:

  • Salsa is now the default JavaScript language service.
  • Folding, the most requested feature, is now available.
  • There is support for localization and accessibility.

In addition, we continued to listen to your issues and feature requests.

Downloads: Windows |
OS X | Linux 32-bit | Linux 64-bit

22.1 Languages - JavaScript

The Salsa JavaScript language service was available as preview in January and it is now the default language service for JavaScript in the February update.

22.1.1 Improvements

The JSDoc comment format is now understood and used to improve IntelliSense proposals and parameter hints:

JSDoc comment format

You now get IntelliSense proposals for properties in ‘ECMAScript 3 style classes’:

ES3 style classes

IntelliSense offers both inferred proposals and the global identifiers of the project. The inferred symbols are presented first, followed by the global identifiers (with the document icon), as you can see in the image above.

The CommonJS module support has been improved as well:

commonjs support

There is now support for JSX/React:

React/JSX Support

**Tip:** To get IntelliSense for React/JSX, install the typings for react-global by running tsd install react-global or typings install dt~react --global from the terminal.

**Tip:** When you use eslint for linting (see below) and you used eslint --init to create an eslint configuration and you answered yes to “Do you use React?”, then the setting experimentalObjectRestSpread is enabled. Support for ObjectRestSpread is not yet provided by Salsa but it is on the roadmap (see #2103).

There is now support for React Native:

React Native Support

**Tip:** To get IntelliSense for React Native, install the typings for react-native by running tsd install react-native or typings install dt~react-native --global from the terminal. Or even better… if you also want debugging support then install the preview of the React Native extension.

**Tip:** There is a known issue in that Salsa Doesn’t Provide IntelliSense When Using Import Statements.

It is now possible to have mixed TypeScript and JavaScript projects. To enable JavaScript inside a TypeScript project, you can set the allowJs property to true in the tsconfig.json.

**Tip:** The tsc compiler does not detect the presence of a jsconfig.json file automatically. Use the –p argument to make tsc use your jsconfig.json file, e.g. tsc -p jsconfig.json.

Finally, the TypeScript compiler tsc can down-level compile JavaScript files from ES6 to another language level.

22.1.2 Migration Notes

The following sections describe a few of VS Code’s features that have changed with the move to Salsa and provide information about maintaining previous behaviors.

22.1.3 Linters

Previously the JavaScript language support provided some linting options enabled by the javascript.validate.lint.* settings. With jshint and eslint, there are powerful linters for JavaScript available. Also, there are now extensions for VS Code available that integrate these linters. Therefore, we have decided to deprecate the built-in linter and Salsa now reports syntax errors only. We strongly recommend that you install and configure a JavaScript linter if your project hasn’t done so already.

In particular, the previous JavaScript infrastructure provided an implicit lint rule which warned about undeclared variables unless they are mentioned in a /*global*/ comment block. This rule is no longer active and needs to be configured in your linter of choice.

Here are the steps to set up eslint:

  • npm install eslint to install eslint into your workspace or npm install -g eslint to install it globally.
  • install the VS Code eslint extension.
  • use eslint --init to create an initial eslint configuration by answering questions or by picking a popular configuration.

**Tip:** If you use JSON as the format of the eslint configuration file, then VS Code can provide you with IntelliSense when you edit the .eslintrc.json file.

This .eslintrc.json corresponds roughly to the lint settings of the old JavaScript infrastructure.

22.1.4 Changes in jsconfig.json

22.1.4.1 exclude lists

The previous JavaScript language service had a built-in list for folders that should be excluded from the project context. This list included the folders: node_modules, bower_components, jspm_packages, tmp, and temp. This implicit behavior has changed in favor of an explicit list defined by the user. Therefore if you use…

  • node exclude the node_modules folder
  • bower exclude the bower_components folder
  • ember exclude the tmp and temp folder
  • jspm exclude the jspm_packages folder
  • webpack then exclude the output folder, e.g., dist.

Tip:** After editing the jsconfig.json, do not forget to run the Reload JavaScript** command to ensure that everything is up to date.

22.1.4.2 Defaults

If you do not have a jsconfig.json in your workspace then the following defaults are used:

  • the exclude list includes the node_modules folder and the folder defined by the out attribute.

Be aware that if you have no jsconfig.json defined to mark the root of your project, then each JavaScript file is considered an island by Salsa. Without a jsconfig.json file, cross-file and Typings file IntelliSense will not work.

22.1.5 js-is-jsx extension deprecation

The js-is-jsx extension is no longer needed since Salsa gives you coloring for JSX constructs inside .js files out of the box. We recommend you uninstall this extension.

22.1.6 No longer supported

Salsa undoubtedly provides a much better experience writing JavaScript applications in VS Code. By moving to Salsa, we give up a few features previously available with our old JavaScript language service:

  • The source language level is now always ECMAScript 6. Previously, there was support to define a lower level using the target attribute inside jsconfig.json. This support has been removed and the target attribute is now only used by tsc to define the target version when a JavaScript file is compiled to a lower ECMAScript version.
  • The previous JavaScript infrastructure attempted to resolve references for AMD modules. This hasn’t worked in all cases and support for AMD to resolve references across files is currently no longer supported.
  • There is no longer support for IntelliSense in script sections inside HTML documents.
  • The javascript.validate.* settings are no longer supported and are ignored (see above).
  • The previous JavaScript infrastructure provided quick fixes to add an undefined variable as a global and to fetch a type definition from definitely typed. These quick fixes are no longer available.
  • A file without a .js suffix that VS Code identifies as a JavaScript file is now treated as a .ts file and you get unexpected type errors (#issue 7291).

22.2 Languages - TypeScript

VS Code now ships with the latest TypeScript 1.8.2 version.

22.2.1 Migration Notes

Note: With the move to TypeScript 1.8.2, you will need to have a jsconfig.json in your workspace for TypeScript definition files (for example node.d.ts) to be picked up.

If you don’t already have a jsconfig.json file in your workspace, add a jsconfig.json file to the root with the compilerOptions:module attribute set:

{
    "compilerOptions": {
        "module": "commonjs"
    }
}

22.3 Languages - C#

C# language support is now an optional install from the Marketplace. You can install it from within VS Code by searching for ‘C#’:

Installing C# extension

or if you already have a project with C# files, VS Code will prompt you to install the extension as soon as you open a C# file.

22.4 Editor

22.4.1 Source Code Folding

The editor now contains a first implementation of code folding. You can turn the feature on and off with the editor.folding configuration setting (File > Preferences > Settings). Once enabled, you can collapse and expand code regions using the folding icons next to the line numbers. Regions that can be folded are shown with a - icon, regions that are already folded with the + icon. The - icon only shows when the mouse is over the gutter.

Source Code Folding

Additionally you can use the following commands from the commands menu (F1) or with keyboard shortcuts:

  • Fold (kb(editor.fold)) folds the innermost uncollapsed region at the cursor
  • Unfold (kb(editor.unfold)) unfolds the collapsed region at the cursor
  • Fold All (kb(editor.foldAll)) folds all region in the editor
  • Unfold All (kb(editor.unfoldAll)) unfolds all regions in the editor

The folding regions are evaluated solely based on the indentation of each line. This first version does not yet support language agnostic folding regions, or folding markers. This is in discussion for an upcoming release (see issue #3422).

22.4.2 IntelliSense Performance

The IntelliSense widget underwent a full rewrite to address some performance problems. It now handles lists of 20,000 extensions in milliseconds, compared to the previous ~10 seconds of lag.

22.4.3 Indentation

Initiated by user request #1228, we have added indentation status in the editor to help with ‘tabs to spaces’ conversion and vice versa. The Status Bar shows whether the Tab key will insert spaces or tabs and the current indentation size in characters.

indentation status

You can adjust the indentation size and toggle between tabs and spaces with three new actions:

indentation actions

22.4.4 Ruler Settings

There is a new setting editor.rulers available. For example, setting it to [80, 120] will display two vertical rulers in the editor, one after the 80th character and one after the 120th character.

22.4.5 Default End of Line Sequence

A new setting files.eol controls the default new line character when creating new files. It defaults to \r\n on Windows and to \n on Linux and OS X.

22.4.6 Word navigation and word separators

Word navigation and word deletion commands updated and now honor a new setting, editor.wordSeparators, when deciding what is a word, regardless of the current language of the file.

22.4.7 Improved usage of web workers

With the adoption of the Salsa JavaScript language service as the default, we could streamline our usage of web workers and now have a dedicated web worker that is language agnostic, which we use for diff computation, link detection or simple textual completions. This reduces the latency of these computations and is memory friendly, as it automatically shuts down when not needed.

22.5 Workbench

22.5.1 Open Definition to the Side

There is now an action to open a definition to the side in the Command Palette (kb(editor.action.openDeclarationToTheSide)).

open definition to the side

22.5.2 Close Other Files

There is now an action to close all other files, in the Working Files’ context menu (kb(workbench.files.action.closeOtherFiles)).

close other files

22.5.3 Switch to a working file from Quick Open

It’s now possible to open a file in the Working Files list from the Quick Open box by prefixing it with ~.

quick open working files

22.5.4 Extension Recommendations

There is a new command Extensions: Show Extension Recommendations for displaying suggested extensions based on your use of VS Code. You can reach this by typing ext recommend (trailing space) in the Quick Open box.

show extension recommendations

The performance of the in-product Extension Gallery (via the Extensions: Install Extension command) has been greatly improved. We introduced a server-side cache which speeds up the request considerably.

22.6 Debugging

22.6.1 VS Code no longer ‘fixes’ Relative Paths in Launch Configurations

In the January milestone, we deprecated the use of relative paths in launch configurations (but still continued to convert relative in absolute paths).
With this milestone, we’ve dropped this automatic fixing in favor of a more transparent strategy: VS Code no longer modifies launch configuration paths when sending them to the debug adapter. This is now the same treatment of paths as for task configurations.

If you haven’t already fixed your launch configuration paths for the January release, then you will now see this (or similar) errors when starting a debug session:

install-mono-debug-help

Just prefixing the relative path with a ${workspaceRoot}/ should fix the problem.

22.6.2 Pre Launch Task Improvements

We have improved the preLaunchTask based on user feedback and feature requests:

  • If preLaunchTask produces an error, debugging does not start and a message with an option to continue debugging despite the error is shown.

pre-launch-task-error

  • If a preLaunchTask is a watching task, debugging does not start before the watching task becomes inactive.
  • If a tasks.json is missing and a preLaunchTask is set, we offer to create a tasks.json for the user.

22.6.3 Support for Node.js ‘nodemon’ Development Setup

The VS Code Node.js debugger now supports an automatic restart mode for the ‘attach’ launch configuration.
This feature is useful if you use nodemon to restart Node.js on file changes.
Setting the launch configuration attribute restart to true makes node-debug automatically try to re-attach to Node.js after a debug session has ended.

On the command line, start your Node.js program server.js:

nodemon --debug server.js

In VS Code, create an ‘attach’ launch configuration:

{
    "name": "Attach",
    "type": "node",
    "request": "attach",
    "port": 5858,
    "restart": true
}

Tip:** Pressing the Stop** button stops the debug session and disconnects from Node.js, but nodemon (and Node.js) will continue to run. So to stop nodemon you will have to kill it from the command line.

**Tip:** In case of syntax errors, nodemon will not be able to start Node.js successfully until the error has been fixed. In this case VS Code will continue trying to attach to Node.js but eventually give up (after 10 seconds). To avoid this you can increase the timeout by adding a timeout attribute with a larger value (in milliseconds).

22.6.4 Function Breakpoints

Instead of placing breakpoints directly in the code, the VS Code Node.js debugger now supports creating breakpoints by specifying a function name.
This is useful in situations where source is not available but a function name is known.

A ‘function breakpoint’ is created by pressing the ‘+’ button in the Breakpoints view header:

function breakpoint

Please note: Node.js support for function breakpoints is limited because:

  • function breakpoints only work for global, non-native functions and
  • function breakpoints can only be created if the function has been defined (seen by Node.js).

22.6.5 Mono Debugging is now an Optional Install

Since C# support in VS Code has been turned into an optional install, we have done the same with the Mono debugger.
The Mono debugger has now become ‘Mono Debug’ on the Visual Studio Marketplace.

You can either install the Mono Debug extension with the VS Code Extensions: Install Extension command or if you already have a Mono based project with a mono launch configuration, simply by starting a debug session. VS Code will then suggest to download and install Mono Debug automatically:

install-mono-debug-help

22.7 Tasks

The eslint-stylish problem matcher changed to use absolute file paths by default. We made this breaking change because the stylish reporter integrated into eslint reports absolute paths by default. If you are using an older version of eslint with the external stylish reporter that reports relative file paths, you can tweak the problemMatcher in a tasks.json file as below to make this combination work:

"problemMatcher": {
    "base": "$eslint-stylish",
    "fileLocation": "relative"
}

22.8 Setup

22.8.1 OS X Shell Command

In OS X, two new commands were added to install the VS Code shell command in the $PATH environment variable list. This makes the previous alias in ~/.bash_profile deprecated and we recommend you to remove it and use this command instead.

OS X Shell Commands

22.8.2 Telemetry Opt Out

Users now can opt out of usage telemetry via the telemetry.enableTelemetry setting.

22.8.3 Improved Command Line Interaction

The command line interface for code has been unified across all platforms and now supports a few arguments such as --help and --version.

22.9 Accessibility

Accessibility has been a constant theme over the past milestones and in February VS Code has been improved across the feature space.

22.9.1 High Contrast Theme

As a part of the accessibility work, the High Contrast theme, which was only available for Windows users, is now enabled for all 3 platforms.

High Contrast Theme

22.9.2 Screen reading

We have turned on by default a new strategy for screen readers in the editor, one that is based on paging the text. From our testing, this is the best option in terms of trade-off between good screen reader support and performance when dealing with very large files.

The Go to Next/Previous Error or Warning actions (kb(editor.action.marker.next) and kb(editor.action.marker.prev)) now allow screen readers to announce the error or warning messages.

22.9.3 Improved Debugger Accessibility

Based on user feedback, we have improved debugger accessibility:

  • Changes in debug state are read out (e.g. ‘started’, ‘breakpoint hit’, ‘terminated’, …)
  • All debug actions are keyboard accessible
  • Focus intuitively moves inside the Debug View and Debug Console
  • Debug hover is keyboard accessible (kb(editor.action.showHover))

22.10 Localization

Support has been added to localize package.json files for extensions and CommonJS code. For localizing CommonJS code, we’ve published a new npm module vscode-nls which helps you with localizing strings in your VS Code extension.

22.11 Extension Authoring

22.11.1 Always install a compatible version of the extension if possible

VS Code will now fallback to installing the latest compatible version of an extension with its own version, in case the latest extension version isn’t compatible. This prevents users from installing extensions that could fail to activate.

22.11.2 Debug Adapter

We now support more OS types for the debuggers contribution point (see #1696 for details). In addition to win, linux, and osx, adapters can now use winx86 in their package.json to specify options specific to a 32-bit Windows:

"debuggers": [{
    "type": "gdb",
    "win": {
        "program": "./bin/gdbDebug.exe"
    },
    "winx86": {
        "program": "./bin/gdbDebug_x86.exe"
    }
}]

22.11.3 Debug Protocol Changes

We have changed the debug protocol in the following (backward compatible) ways:

  • Feature negotiation:

  • A boolean supportsConditionalBreakpoints in Capabilities indicates whether the debug adapter supports conditional breakpoints. If a debug adapter does not support conditional breakpoints, a breakpoint which has a condition set is shown with an exclamation mark:

    breakpoint-with-exclamation-mark

  • A boolean supportsFunctionBreakpoints in Capabilities indicates whether the debug adapter implements function breakpoints. VS Code will only use the new function breakpoint request of the debug protocol if this feature is enabled.

  • A boolean supportsEvaluateForHovers indicates whether the debug adapter supports a side effect free EvaluateRequest. If this feature is enabled, VS Code will use the evaluate request to populate the hover with information about the object under the mouse pointer. If it is disabled, VS Code uses the information from the Variables viewlet.

  • An optional exceptionBreakpointFilters capability that lists the filters available for the setExceptionBreakpoints request. With this, a debug adapter can contribute the options shown in the breakpoint viewlet:

    breakpoint-options

  • An optional restart attribute has been added to the TerminatedEvent which a debug adapter can use to request a session restart.

22.12 Notable Bug Fixes

  • 105: Enable code folding and collapsing
  • 439: ext install is slow
  • 1228: Add option to convert tabs to spaces
  • 2490: Improve IntelliSense perf
  • 3127: code . opens the current directory, code .. also opens the current directory - not the parent
  • 3894: [Handlebars] Curly braces edit issuess
  • 3899: [folding] sections are still folded when disabled in preferences
  • 3903: [js] syntax highlight for ‘var’ and ‘function’ not working in Default VS theme
  • 3509: Smoke Test: Don’t get cross file intellisense in JS

Here are the closed bugs and the closed feature requests for the February update.

22.13 Thank You

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

22.14 VS Code Blog

You might not have noticed but we’ve moved the VS Code blog to our website. We hope you find this more convenient and easier to search across all of our documentation. Check out the recent post about the Chrome Debugger extension!

# May 2017 (version 1.13)

22.15 Insiders Release

Welcome to the Insiders build. These are the preliminary notes for the May 1.13 release of Visual Studio Code. As we get closer to the release date, you’ll see details below about new features and important fixes.

Until the May release notes are available, you can still track our progress:

We really appreciate people taking a look at our new features as soon as they are ready so check back here often and learn what’s new to try out.

If you find issues or have suggestions, you can enter them in the VS Code repository on GitHub.

<!– In-product release notes styles. Do not modify without also modifying regex in gulpfile.common.js –>
<a id=“scroll-to-top” role=“button” aria-label=“scroll to top” href=“#”><span class=“icon”></span></a>
<link rel=“stylesheet” type=“text/css” href=“css/inproduct_releasenotes.css”/>

23 January 2016 (0.10.9)

Hi,

We are back from the holidays and are rolling again, looking forward to the Build 2016 conference. For //build, we’re focused on making VS Code accessible, available in additional languages, and stabilizing on a 1.0 API. Outside of these fundamentals, perhaps the most impactful work item in the January release is enabling the Salsa preview in VS Code. Read more below, give it a try, and let us know what you think.

Downloads: Windows | OS X | Linux 32-bit | Linux 64-bit

23.1 JavaScript - Salsa Preview

The JavaScript language service in VS Code has always been powered by TypeScript. We are migrating to a new JavaScript language service implementation called Salsa. Salsa will become available with TypeScript 1.8 but for the January update, we are providing way to preview Salsa in VS Code.

23.1.1 Salsa Improvements

Salsa provides important improvements over the existing JavaScript language service.

The JSDoc comment format is now understood and used to improve IntelliSense proposals and parameter hints:

JSDoc comment format

You now get IntelliSense proposals for properties in ‘ECMAScript 3 style classes’:

ES3 style classes

IntelliSense offers both inferred proposals and the global identifiers of the project. The inferred symbols are presented first, followed by the global identifiers (with the document icon), as you can see in the image above.

The commonjs support has been improved as well:

commonjs support

**Tip:** When using commonjs, exclude the node_modules folder using the exclude property in jsconfig.json. This is due to issue 6673 which is fixed but not yet in typescript@next.

There is now support for JSX:

JSX Support

**Tip:** To get IntelliSense for React/JSX, install the typings for react-global by running tsd install react-global from the terminal.

Salsa also understands JSX constructs inside JavaScript (.js) files to support React Native development. We haven’t updated the grammar for .js files yet but you can enable JSX syntax coloring for JS using the js-is-jsx extension. This extension tell VS Code to treat .js files as .jsx files so that the JSX syntax coloring is used.

It is now possible to have mixed TypeScript and JavaScript projects. To enable JavaScript inside a TypeScript project, you can set the allowJs property to true in the tsconfig.json.

**Tip:** The tsc compiler does not detect the presence of a jsconfig.json file automatically. Use the –p argument to make tsc use your jsconfig.json file, e.g. tsc -p jsconfig.json.

Finally, the TypeScript compiler tsc can down-level compile JavaScript files from ES6 to another language level.

23.1.2 Changes from the existing VS Code JavaScript support

Salsa will undoubtedly provide a much better experience writing JavaScript applications in VS Code. By moving to this new service, we give up a few features previously available with our custom JavaScript language service.

  • When using Salsa, the language level is always ECMAScript 6. In the existing JavaScript language service, the default level was ES6 but there was support to define a lower level using the target attribute inside jsconfig.json. This support has been removed and the target attribute is now only used by tsc to define the target version when a JavaScript file is compiled to a lower ECMAScript version.
  • The existing JavaScript language service implicitly excluded some folders from the project, see the JavaScript topic. This is no longer the case and you must exclude these folders explicitly in your jsconfig.json file.
  • Salsa flags syntax errors but the JavaScript linting options javascript.validate.lint.* defined in the user settings are no longer supported. To get these linting options back, we recommend that you use a linter combined with a VS Code linter extension like ESLint or JSHint.
  • Salsa doesn’t support the AMD module system.

23.1.3 Enabling Salsa

To enable Salsa for your workspace:

  • Set the environment variable VSCODE_TSJS. On OS X, it is recommended that you change this in your .bash_profile using export VSCODE_TSJS=1. That way the environment variable is persisted.
  • Salsa requires TypeScript 1.8 but the final 1.8 release isn’t available yet. Therefore, you need to install the nightly TypeScript build. You have two options:
  • Install TypeScript locally into your workspace using npm install typescript@next. VS Code will pick up the TypeScript version from there.
  • Install TypeScript globally to share the installation across workspaces. In this case, you install it using npm install -g typescript@next. You then have to tell VS Code the install location using the typescript.tsdk setting. Set typescript.tsdk to the path of the lib folder containing the tsserver.js file of the installed TypeScript module.

Please note, the TypeScript nightly is continually being updated. During our testing, we have been very successful using typescript@1.9.0-dev.20160128.

You can verify that you have Salsa enabled and you have an installed TypeScript version that supports Salsa by checking the status indicator in the Status Bar. This shows that all is OK:

Salsa status

When the TypeScript version doesn’t support Salsa, you will see the indicator below. If you hover over the status indicator, you will see the path to the TypeScript installation that you have configured.

Salsa status failure

23.2 Editor

23.2.1 New Default Themes

The Light and Dark themes have been in the center of attention recently as colors were added and removed again. More colors became visible with the switch to TextMate tokenizers in November. In December, we decided to remove some of the newly added colors again to stay compatible with the classic Visual Studio Light and Dark themes.

From the feedback in GitHub issues 1270, 1470, and others, we learned that there are fans of both the classic Visual Studio Light and Dark themes as well as the more colorful versions. So for the January release, we decided to bring the colors back with two new built-in themes: ‘Light+’ and ‘Dark+’. If you installed the theme preview as an extension, you can now uninstall it.

In addition to the 4 major colors in the Visual Studio themes (comments, strings, numbers and keywords), the ‘plus’ themes add colors for:

  • control flow keywords
  • type names
  • function names
  • variable and parameter names

Light+ theme

Dark+ theme

New installations will get the new Dark+ theme as the default. Existing installations using the previous Light or Dark themes can switch to the new Dark+ or Light+ theme using Color Theme command.

23.2.2 Keyboard Accessibility

You will find that VS Code provides an exhaustive list of commands in the Command Palette (kb(workbench.action.showCommands)) so that you can run VS Code without using the mouse. However, some parts of the UI could not be operated without using the mouse. We made a pass over these locations and added support to use the kbstyle(Tab) key to jump between UI controls that you can interact with. Using kbstyle(Tab) or kbstyle(Shift+Tab) to jump between elements with actions in the UI is a very common pattern for keyboard accessibility. In addition to that, we now also draw an indicator around the UI element once the element gains focus.

Some areas where you can now jump to using keyboard only:

  • View switcher
  • Header of collapsible sections in a view to expand/collapse
  • Actions in views and sections
  • Actions for items in the tree

This is just the beginning of our journey to become more keyboard accessible, expect more areas to follow in the future!

23.2.3 Experimental screen reader support in the editor

We have added an experimental mode that can be enabled with the editor.experimentalScreenReader key in settings or for the current session with kbstyle(Ctrl+Shift+R). This causes the editor to place all the current text in the opened file inside the <textarea> we use for user input. We have done our initial testing with the NVDA screen reader on Windows and have uncovered some serious performance issues and glitches caused by Chromium which we continue to work on. We have also added kbstyle(Alt+F1) that presents a tooltip explaining how to toggle this mode on and off. We have also improved keyboard navigation around kbstyle(Tab), specifically all read-only editors no longer trap the kbstyle(Tab) key. Also, kbstyle(Ctrl+M) continues to act as a toggle for trapping kbstyle(Tab).

23.2.4 Localization

We also started work on localizing VS Code for different locales. We put tooling in place to externalize strings and to create language bundles. The screen shot below shows VS Code running under a German locale.

VS Code in German

Please note that the translation effort for VS Code has not been completed yet and it will still take a while until we ship VS Code for languages other than English.

23.2.5 Ligatures for VS Code

VS Code now supports fonts with programming ligatures, like Hasklig and Fira Code. Those fonts provide compositions for character sequences commonly used in programming, as =>, >=, != etc. Enable ligatures with new editor.fontLigatures setting and pick a font with programming ligatures. Special thanks to @mattblagden for initiating this.

Ligatures for Code

23.2.6 Find Widget Improvements

The Find widget was updated to make all of its functions work regardless of the number of results. It is now possible to Find, Replace, etc. well beyond the first 1000 find matches. For performance reasons, the Find widget still only highlights the first 1000 matches. We have also improved the tab order in the widget.

The refactoring allowed us to introduce the “X of Y” display, such that now you can tell in a glance how many results and where you are in that list.

We also added two new actions, “Find Next Selection” (kb(editor.action.nextSelectionMatchFindAction)) and “Find Previous Selection” (kb(editor.action.previousSelectionMatchFindAction)), that allow you to jump to the next or previous matches without losing editor focus. Thanks to @ajkerrigan, there are now key bindings for the “Replace” and “Replace all” actions.

Find widget counters

23.2.7 Input Handling

We changed input handling in the editor to allow software such as UniKey (used for Vietnamese input) or AutoHotKey (used for keyboard automation) to work with VS Code.

23.2.8 Configurable Cursor Style

We added a new editor option editor.cursorStyle that can be set to "block". Special thanks to @markrendle for his pull request.

23.2.9 Auto Save

VS Code always supported automatically saving dirty files after one second (File | Auto Save). We received a lot of feedback that users want more control over when VS Code should save dirty files. The setting is now in the settings.json configuration file and provides more options:

  • files.autoSave: Can be off to disable auto save, afterDelay to save files after a configured delay and onFocusChange to save files when focus moves out of the editor of the dirty file.
  • files.autoSaveDelay: Configures the delay in milliseconds when files.autoSave is configured to afterDelay.
  • This setting can be configured either globally for the user or per workspace through the workspace settings (Preferences | Workspace Settings).

Note: If you had Auto Save enabled previously, we will migrate your setting into the settings.json file automatically. You will not see any dirty indicators in the UI if you configure auto save for 1 second or below. In all other cases, you will see the dirty indicators throughout the UI.

23.2.10 File Picker

Some useful changes around the file picker (kb(workbench.action.quickOpen)) include:

  • Fuzzy matching is now enabled by default and the previously introduced setting filePicker.alternateFileNameMatching is no longer needed.
  • You can open any file (including line/column pattern at the end) that exists on disk by typing the full path or full workspace relative path even if your exclude settings hide it otherwise.

23.2.11 Full IntelliSense Documentation

We improved the interaction and rendering of IntelliSense suggestions which have more complete documentation. A blue icon will appear on the right of the suggestion’s documentation:

IntelliSense full documentation icon

Clicking it will display the full documentation for that suggestion. It’s also possible trigger IntelliSense a second time to enter this mode
(kb(editor.action.triggerSuggest)):

Show IntelliSense full documentation

23.3 Workbench

23.3.1 Hide the Menu Bar (Windows, Linux)

We added a new action to hide the menu bar on Windows and Linux (View | Toggle Menu Bar). You can still access the menu pressing the Alt key.

23.3.2 Horizontal panel

We now show the output and debug consoles horizontally:

Horizontal output panel

23.4 Debugging

23.4.1 Rich Object Hover

We are now using a tree in the debug hover to allow better rich object inspection:

debug hover

23.4.2 Conditional Breakpoints

We now support setting conditional breakpoints that are hit only when the specified condition is true. Please note, the underlying debug target, such as Node.js, must support conditional breakpoints for this feature to work.

conditional breakpoints

23.4.3 Changed Variable Indication

We now indicate in the Debug and Watch views which variables have changed values between step events.

variables changed

23.5 Node.js Debugging

23.5.1 Source Maps with Inlined Source

Node.js debugging now supports source maps with “inlined source” in addition to “inlined source maps” which were already supported. To avoid confusion, here is a brief explanation of these two source map options. “Inlined source” and “inlined source maps” are orthogonal features and VS Code supports both either alone or in combination:

  • *Inlined source maps:* The contents of the source map does not live in a file but is a data URL at the end of the generated file.
  • Inlined source: The contents of the original source file does not live in a file but is included in the source map.

The strategy for which situations VS Code will use “inlined source” is as follows:

  • VS Code always tries to locate the source on disk first.
  • If it cannot find the source (e.g. because there is none in the VS Code workspace or because the paths in the source maps are broken), VS Code will use the “inlined source” if available.
  • If there is no inlined source, VS Code will fall back to get the file contents from Node.js itself.

Whenever the editor contents is not loaded from the file system but comes from the debugger backend, the editor will be in read-only mode and the “origin” of the editor contents is shown in the editor title like this:

Editor showing inlined source

23.5.2 Remote Debugging

The followings improvements enable VS Code to support remote debugging, includes debugging into a Docker container:

  • The attach launch configuration now supports an address attribute where a remote host can be specified. Please note that remote debugging is only supported on recent versions of Node.js (>= 4.x).
  • The attach launch configuration now supports a localRoot and a remoteRoot attribute that can be used to map paths between a local VS Code project and a (remote) Node.js folder. This works even locally on the same system or across different operating systems. Whenever a code path needs to be converted from the remote Node.js to a local VS Code path, the remoteRoot path is stripped off the path and replaced by localRoot. For the reverse conversion, the localRoot path is replaced by the remoteRoot.

23.5.3 launch.json relative paths not automatically converted to absolute ones

In order to achieve consistency across our configuration files, we plan for the February release to no longer automatically convert certain paths from relative to absolute in launch.json. We recommend that for the program, cwd, outDir, and runtimeExecutable attributes, you prefix your relative paths with the ${workspaceRoot} variable as soon as possible. To make it easier for you to find the affected paths that need this treatment, we highlight them with a green squigglies for the January release. (Please note: since we continue to automatically convert paths for the January release, your launch configurations will continue to work).

23.5.4 “–nolazy” option not automatically added

In order to make sure that breakpoints are hit reliably, VS Code automatically added the --nolazy option when launching Node.js. With the advent of Node.js alternatives that do not support this option (e.g. Chakra), we’ve removed this automatic behavior. If you see that breakpoints are not hit reliably in Node.js applications, please verify that your launch configuration sets the --nolazy option explicitly via the runtimeArgs attribute.

23.6 Mono debugging

23.6.1 Support for VS Code Debug Console

For VS Code Mono debugging support, we’ve added an externalConsole attribute, which controls whether the Mono target application is launched in an external console or in the built-in Debug Console (the default). Please note that the built-in Debug Console does not support keyboard input for your application.

23.7 Extension Authoring

23.7.1 API Consumption

When you write an extension for VS Code, you are developing it against a set of APIs that we define through a file called vscode.d.ts. You can see this file in our repository