猫史档案馆


April 2020 (version 1.45)五

用户:datacatdatacat查看:0 回复:0 评论:0 创建时间:2020-06-13T15:03:35


Extension authoring New theme colors for editor tabs

New colors were a喵ed to further theme the workbench editor tabs:

New theme color for editor title border

The existing color editorGroupHeader.tabsBorder was changed to render a border below editor tabs but above breadcrumbs. A new color editorGroupHeader.border lets you render a border below the editor group header (for example, below breadcrumbs if enabled) to restore the previous behavior of editorGroupHeader.tabsBorder.

Deprecating and archiving of the vscode NPM module

In June 2019, we split the vscode module into @types/vscode and vscode-test in light of the event-stream incident. Today, a security alert for minimist has caused security alerts for extensions that still depend on vscode, which depends on mocha@5.2.0 and therefore minimist@0.0.8. Unfortunately, mocha@5.2.0 no longer receive updates and upgrading to a new mocha version would break existing functionalities.

We published a new version of vscode that removes some unnecessary dependencies. We also archived the repository and deprecated the vscode module on NPM. Please migrate to @types/vscode and vscode-test.

New Completion Item Kinds

There are two new entries to vscode.CompletionItemKind that represent issues and users. These can be used for instance to suggest usernames when a喵ing TODO tags.

Working with URIs

We have a喵ed a vscode.Uri.joinPath utility. It is a factory function that creates new URIs by joining path segments with an existing URI. Think of this as Node.js' path.join utility but for URIs.

For extensions, VS Code exposes the URI where extensions are installed via Extension.extensionUri and via ExtensionContext.extensionUri. With the join utility, you can now create URIs for resources of your extension.

For example:


const fileUri = vscode.Uri. joinPath (context.extensionUri, './file.png' );
const bytes = await vscode.workspace.fs. readFile (fileUri);

debug/callstack/context menu inline group

VS Code now supports contributions to the debug/callstack/context menu inline group. Commands contributed to this group will be rendered inline in the Call Stack when a user hovers over the Debug Session element.

Call Stack inline contribution

New Debug theme colors

There are new colors for styling the Debug view:

Source control management

New preserveFocus argument to open resource commands

When invoking the SourceControlResourceState.command command, an additional preserveFocus: boolean argument will be passed, which lets extension authors to provide a better user experience.

Input text mimetype

The Source Control input text now has a dedicated mimetype: text/x-scm-input.

Control input box visibility

Extensions can now control the visibility of the Source Control input box for each repository using the SourceControlInputBox.visibleproperty.

Git

Remote source providers

The Git extension API now allows other extensions to provide remote sources in order to participate in the Git: Clone command.

Here's an example by the GitHub Pull Requests and Issues extension:

Clone from GitHub

Credential providers

The Git extension API was expanded so that extensions can provide authentication credentials in order to authenticate Git commands invoked against HTTPS Git repositories within the workbench and Integrated Terminal.

SignatureInformation.activeParameter

The new activeParameter property on SignatureInformation lets you specify the active parameter for every signature individually. When provided, this overrides the top level SignatureHelp.activeParameter property.

Strict null fix for EventEmitter

In VS Code 1.44 and below, the argument to EventEmitter.fire is optional:

// Valid in VS Code 1.44
const emitter = new EventEmitter < number >();

emitter. event (( x : number ) => console . log (x));

// Calling fire with no argument was valid but resulted in the `x` above being `undefined`
emitter. fire ();

This violated strict null checking but did not cause compile errors.

In VS Code 1.45, the fire now requires an argument. If you still want to be able to call .fire() with no arguments in your source code, use new EventEmitter<void>.

Language Server Protocol

Work has started on the 3.16 version of the specification. As a first step, the Call Hierarchy support moved out of the proposed state. Please note that the 3.16 spec is not yet final and, depending on feedback, may still change.

Proposed extension APIs

Every milestone comes with new proposed APIs and extension authors can try them out. As always, we are keen on your feedback. This is what you have to do to try out a proposed API:

Note that you cannot publish an extension that uses a proposed API. There may be breaking changes in the next release and we never want to break existing extensions.

Contribute to terminal environments

This new proposed API was introduced last month so that extension authors can contribute to terminal environments. This month has mainly been applying some UI on top of the feature and polishing it up. There is now a warning icon when a terminal has a "stale" environment, which shows a rich hover explaining what's going to change and includes a convenient Relaunch terminal action. There's also an information icon available when changes are active but this is disabled by default.

Terminal stale environment warning

 

Providing debug configurations dynamically

We have updated the debugging extension API to give debug extension authors a way to add debug configurations dynamically, based on information found in the workspace or project. These debug configurations appear in the same UI locations where static debug configurations from the launch.json are shown.

In this release, dynamic debug configurations are shown in the Debug view's configuration dropdown and the Select and Start Debugging Quick Pick. In a future release, we are considering showing them in the "Welcome" view as well.

The new API is based on the provideDebugConfigurations method of the existing DebugConfigurationProvider. Until this release, the provideDebugConfigurations was called by VS Code to provide the initial "static" debug configurations to be copied into a newly created launch.json. With the new API, a DebugConfigurationProvider can now be registered via vscode.debug.registerDebugConfigurationProvider for the "dynamic" case by passing the value DebugConfigurationProviderTriggerKind.Dynamic to the new optional triggerKind argument. With this new registration, VS Code will call the provideDebugConfigurations method whenever the list of all debug configurations is about to be presented in the UI.

In order to activate extensions that make use of this new API on time, a new activation event onDebugDynamicConfigurations:<debug type>has been introduced. The <debug type> is mandatory and denotes for which debugger the dynamic debug configurations are specified.

usage example can be found in Mock Debug.

Binary Custom Editor API

We spent this iteration reworking the proposed API for binary custom editors to prepare it for stabilization. As a reminder, custom editors let extensions provide their own editor user interface in place of VS Code's normal text editor. We've already stabilized support for custom editors for text based files. The proposed API extends custom editors to binary file formats such as images or hex dumps.

A custom editor for binary files

We want your feedback on this API so that we can hopefully finalize it next iteration. Check out the custom editor extension sample to review an example implementation of a custom editor for binary files. The Custom Editor API documentation now also covers custom editors for binary files.

Please let us know if this API works for you or if you run into any problems implementing your custom editor.

 

emotion_编程猫_搓头


回复

上一页1 页 / 共 0下一页