Visual Studio Code

2022年10月（版本1.73）

更新 1.73.1: 本次更新解决了这些问题。

下载：Windows: x64 Arm64 | Mac: Universal Intel silicon | Linux: deb rpm tarball Arm snap

欢迎来到2022年10月发布的Visual Studio Code。此版本中有许多更新，我们希望您会喜欢，一些关键亮点包括：

如果您想在线阅读这些发布说明，请访问更新在code.visualstudio.com上。

内部人员：想要尽快尝试新功能吗？您可以下载每晚的内部人员版本，并在更新可用时立即尝试最新更新。

可访问性

新的音频提示

有新的音频提示来帮助处理任务和终端。

  • 任务完成 - 表示任务已完成的声音（由audioCues.taskCompleted设置控制）。
  • 任务失败 - 当任务失败时发出声音 (audioCues.taskFailed).
  • 终端快速修复 - 如果当前行有可用的快速修复 (audioCues.terminalQuickFix)。

屏幕阅读器模式下的文字换行

在屏幕阅读器模式下运行VS Code时，为了防止屏幕阅读器体验下降，已禁用自动换行。此问题已修复，可以通过editor.wordWrap启用。

无障碍设置标签

现在可以使用accessibility标签来提高与无障碍相关设置的可发现性。

首选项：打开辅助功能设置命令使用@tag:accessibility过滤器打开设置编辑器。

工作台

在搜索中包含和排除文件夹

在搜索结果树视图中右键单击文件夹时，上下文菜单中现在有两个新选项。

  • 选择限制搜索到文件夹会将选定的文件夹路径添加到要包含的文件文本框中。向此文本框添加路径将限制搜索结果仅符合列出的路径或模式。

    使用限制搜索到文件夹

    主题: GitHub Dark Dimmed (在 vscode.dev 上预览)

  • 选择从搜索中排除文件夹会将选定的文件夹路径添加到要排除的文件文本框中。在此处添加路径将排除符合所列路径或模式的任何搜索结果。

    使用排除文件夹搜索

    主题: GitHub Dark Dimmed (在 vscode.dev 上预览)

命令中心模式快捷键

在命令中心新增了一个顶部部分，以便更容易发现如何导航到文件、运行命令等。

这个简短的模式列表还提供了快捷键提示，这样您可以直接跳转到最常用的模式（例如转到文件），而无需通过命令中心。

命令中心UI默认不在标题栏中显示，但您可以通过窗口：命令中心（window.commandCenter）设置或右键单击标题栏并勾选命令中心来启用它。

设置编辑器工作区信任和政策指示器

由于受限模式工作区或组织策略管理而未应用的设置现在使用指示器来显示其状态。用户即使在受限模式工作区中也可以读取和写入工作区设置（这始终可以通过settings.json文件实现），但在计算受限工作区中使用的设置的最终值时，不会考虑工作区设置值。

默认的浅色主题也进行了一些调整，在指示器区域中的codicon渲染更加清晰，焦点边框也更加紧凑。

受限工作区设置演示，显示键盘导航和切换复选框，即使设置受限

大纲默认折叠状态

有一个新的设置 outline.collapseItems 控制 大纲 视图中项目的默认折叠状态。默认值为 false，这意味着大纲项目默认是展开的。将其设置为 true 可以使大纲项目默认折叠。此设置可以按语言设置，并且也适用于笔记本。

重新排列视图菜单

在VS Code菜单栏的“视图”菜单中，最后一组是一个不断增长的编辑器操作列表。为了平衡菜单的增长和功能，我们将主要与外观相关的项目移到了外观子菜单下。自动换行和粘性滚动选项仍保留在菜单底部的原始位置。

更新后的视图菜单，外观子菜单已展开

主题: GitHub Light Default (在 vscode.dev 上预览)

输入界面的圆角

文本输入框、文本区域和下拉菜单现在都显示圆角，以匹配之前版本中应用于按钮的相同样式。

搜索输入框中带有圆角的文本输入

快速选择列表样式更新

Quick Pick UI 中使用的列表样式已进行了轻微的更新，增加了圆角和左右边距。

列表视图的更新图标

平面列表和树形列表视图现在使用更易读的 codicons 来表示列表类型。

侧边栏前景色

次级侧边栏通常模仿主侧边栏的主题，但并非所有主题键都被正确应用。现在，次级侧边栏正确地使用了"sideBar.foreground"主题键。

在右侧的主侧边栏（带有资源管理器）和左侧的次侧边栏（带有大纲视图）都使用了相同的粉红色前景色。

次级侧边栏，前景色为粉色，与主侧边栏相匹配

主题: GitHub Light Default (在 vscode.dev 上预览)

不再显示“折叠范围过多”通知

出于性能原因，我们将编辑器中显示的折叠范围数量限制为5000。可以通过设置editor.foldingMaximumRegions来配置此限制。当超过限制时，VS Code 过去会显示通知。现在，状态栏中的语言状态悬停会显示该信息。

语言状态中的折叠限制警告

默认折叠提供者

通常，当一种语言有多个折叠提供程序处于活动状态时，VS Core 会尝试合并结果。如果存在冲突的范围，某些范围将被丢弃。此外，并非所有折叠提供程序都能与其他提供程序结合使用。

新的editor.defaultFoldingProvider设置允许您选择要使用的折叠提供程序。提供程序的名称是贡献它的扩展的扩展ID（{publisher}.{extension}）。

以下示例将（假设的）扩展 aeschli.better-folding 的折叠提供程序设置为 JavaScript 的默认值。

    "[javascript]": {
            "editor.defaultFoldingRangeProvider": "aeschli.better-folding"
    }

为每个输出通道设置日志级别

您现在可以使用命令Developer: Set Log Level...为每个日志输出通道设置日志级别。当您只想查看特定日志输出通道的更多日志时，这非常有用。该命令将首先显示输出通道列表，选择其中一个后，系统将提示您设置日志级别。

开发者：设置日志级别命令的输出通道下拉列表

你也可以从命令行设置每个扩展的日志级别。这在你想查看特定扩展的更多日志时非常有用。例如，以下脚本允许你启动VS Code，并将Git扩展的日志输出通道的默认日志级别设置为debug。

code --log vscode.git:debug

新的 list.collapseAllToFocus 树视图命令

一个新的命令 list.collapseAllToFocus 允许你递归地折叠当前聚焦的树项。这在你想折叠一个非根树项的所有子项时非常有用。该命令没有默认的键绑定，但你可以通过键盘快捷键编辑器添加你自己的键盘快捷键（⌘K ⌘S (Windows, Linux Ctrl+K Ctrl+S)）。

合并编辑器

在这个里程碑中，我们继续完善合并编辑器，此次更新包含了一些错误修复和一些新功能。

接受双方追加的冲突

在此版本中，接受传入和接受当前始终可以选择。当两个选项都被选中时，合并编辑器会附加相应的更改行。

在下面的短视频中，RelativePattern 被导入了两次，因为两行都被接受了：

双方如何被接受的屏幕录制

当冲突可以在字符级别上无冲突地解决时，会显示接受组合选项，并可用于自动解决冲突。

在下面的视频中，两个符号都被导入到同一个导入语句中：

组合被接受的屏幕录制

与基础对比的差异装饰

当基础视图打开时，会显示当前聚焦侧和基础之间的差异。此差异视图可用于更好地理解传入和当前中的更改。

显示传入、当前和基础之间差异的屏幕录制

差异算法改进

合并编辑器的默认差异算法已更改。新的差异算法针对合并场景进行了优化。在常见情况下，差异块的数量被最小化，并且插入位置得到了优化。如果新算法导致问题，可以使用设置 "mergeEditor.diffAlgorithm": "smart" 切换回之前的算法（现在默认是 experimental）。

以下截图展示了插入操作的改进。请注意，两个差异都是正确的，但新行为更清晰地突出了插入的文本：

旧行为：

旧的行为在新旧文本中都高亮显示

新行为：

新行为仅突出显示新文本

新的差异算法目前仅在合并编辑器中默认启用。如果您希望常规差异编辑器也使用新的差异算法，可以设置"diffEditor.diffAlgorithm": "experimental"。

导航通过冲突

您现在可以点击冲突计数器跳转到下一个未处理的冲突：

点击冲突计数器跳转到下一个冲突

语言

Markdown 文件重命名/移动时自动更新链接

厌倦了在移动或重命名文件时不小心破坏了Markdown中的链接或图片吗？试试新的markdown.updateLinksOnFileMove.enabled设置！

启用此新设置后，当在VS Code资源管理器中移动或重命名文件时，VS Code将自动更新Markdown中的链接和图像：

Markdown文件链接在文件移动和重命名时更新

您可以使用markdown.updateLinksOnFileMove.include来控制受影响的文件类型。默认情况下，它对所有Markdown文件和常见图像文件格式启用。

Markdown 插入链接命令

新的 Markdown: 插入工作区文件链接 和 Markdown: 从工作区插入图片 命令允许您使用文件选择器快速插入链接和图片到您的 Markdown 中：

请记住，这些命令只是向您的Markdown文件添加链接和图像的一种选择。您也可以使用Markdown路径补全来实现这一点，甚至可以从VS Code的资源管理器中拖放文件来插入链接或图像。

Markdown 未使用和重复链接定义诊断

我们内置的Markdown验证现在可以提醒您未使用或重复的链接定义。您可以通过markdown.validate.enabled启用此功能：

关于重复链接定义的警告

如果您想更精细地控制这些错误，您可以使用这些markdown.validate设置来禁用这些错误（ignore）或更改它们的严重性（warning，error）：

  • markdown.validate.duplicateLinkDefinitions.enabled
  • markdown.validate.unusedLinkDefinitions.enabled

还有一个快速修复功能可以删除重复或未使用的链接定义。

Markdown 链接出现高亮

Markdown中的链接出现高亮显示当前文档中使用光标下链接的所有位置：

高亮显示链接的所有出现

请注意，当光标位于文档中的第一个链接时，所有指向First Header的链接以及标题本身都会在文档中和文档右侧的边栏中高亮显示。

此功能默认关闭。要启用它，请打开markdown.occurrencesHighlight.enabled设置。

新的Razor语法高亮语法

VS Code 有一个新的、维护更好的 Razor 语法高亮显示，用于 Razor 文件。新的语法正在积极维护，并修复了旧语法中存在的问题。

网页版VS Code

改进的分支创建和保护工作流程

当你在VS Code for the Web中的GitHub或Azure Repos仓库时，提交到受保护的分支现在会通知你当前分支受保护，并提示你创建一个新的分支。

此流程还将遵循以下设置：

  • git.branchPrefix 允许您使用配置的前缀预填充分支名称快速输入。
  • "git.branchProtectionPrompt": "alwaysCommitToNewBranch" 允许你在尝试提交到受保护的分支时跳过提示，直接进入创建新分支的快速输入。

此外，当您创建新分支时，可以通过配置"remoteHub.switchToCreatedBranch": "always"来绕过是否切换到新创建分支的提示。

上述所有内容也适用于在桌面版VS Code上使用GitHub Repositories或Azure Repos扩展时。

Web中的本地化改进

几个月前，我们开始为VS Code for the Web进行本地化工作。到目前为止，VS Code核心和扩展中静态声明的字符串已经能够被本地化。在这个迭代中，我们完成了拼图的最后一块：扩展代码中的字符串。这是由于我们上个月提出的本地化API的最终确定而得以实现的。

请密切关注VS Code的更多本地化进展，因为我们将在所有扩展中继续采用这个新的API。如果你是扩展作者，你可以在vscode-l10n仓库中了解更多关于新API的信息。

对扩展的贡献

Python

迁移到isort扩展

在我们2022年5月的发布中，我们宣布了一个新的isort扩展，它与Python扩展一起工作以排序导入。例如，当您打开一个文件并且导入不符合isort标准时，它将显示错误诊断并提供代码操作来修复导入顺序。在此版本中，我们正在迁移以使用独立的isort扩展，而不是通过自动安装与Python扩展一起使用的内置isort支持。

Pylance 默认关闭自动导入

自从Pylance首次实现自动导入功能以来，我们收到了很多反馈，关于当例如意外接受建议时，自动将导入添加到文件中可能会让人感到困惑，有时甚至令人烦恼。从这个版本开始，默认情况下，使用Pylance时将不再自动导入包。如果您想为您的Python项目重新启用自动导入，可以通过设置"python.analysis.autoImportCompletions": true来实现。

Pylint 和 Flake8 扩展推荐

在我们之前的发布 版本中，我们宣布了新的Pylint和Flake8扩展，这些扩展通过语言服务器协议（LSP）与Python扩展协同工作，以提供代码检查功能。在此版本中，如果您仍在使用Python扩展内置的Pylint和Flake8功能，我们会显示通知，提示您安装这些新扩展。

推荐安装Pylint扩展的通知，带有安装按钮

远程开发

远程开发扩展，允许您使用容器、远程机器或Windows Subsystem for Linux (WSL) 作为全功能的开发环境。此版本的亮点包括：

  • 开发容器 模板 - 基于现有模板快速创建开发容器。
  • 开发容器 功能 - 通过包含预打包的功能（或 创建你自己的！）来增强开发容器的能力
  • 创建一个没有起始文件夹的新开发容器。

您可以在远程开发发布说明中了解新扩展功能和错误修复。

GitHub 拉取请求和问题

继续在GitHub Pull Requests and Issues扩展上进行工作，该扩展允许您处理、创建和管理拉取请求和问题。查看0.54.0版本的更新日志以了解其他亮点。

预览功能

TypeScript 4.9

此更新包括对即将发布的TypeScript 4.9版本的支持。有关TypeScript团队当前工作的更多详细信息，请参阅TypeScript 4.9迭代计划。一些编辑器工具的亮点包括：

要开始使用 TypeScript 4.9 的夜间构建版本，请安装 TypeScript Nightly 扩展。

设置配置文件

我们在过去的几个月里一直在努力支持VS Code中的设置配置文件，这是社区中最受欢迎的需求之一。此功能可以通过workbench.experimental.settingsProfiles.enabled设置进行预览。尝试一下，并通过在vscode仓库中创建问题或在问题#116740中评论来给我们反馈。

显示同步的配置文件数据

您现在可以在同步活动（远程）视图中查看为每个配置文件同步的数据。这对于理解每个配置文件同步了哪些数据非常有用。

同步活动（远程）视图显示配置文件的历史记录

注意： 此功能目前仅在 Insiders 版本的 VS Code 中可用。

扩展开发

为工作区编辑提供元数据

现在，应用工作区编辑的API允许扩展提供元数据，例如用于将编辑标记为重构。编辑器将尊重这些额外的元数据，并在重构后自动保存（设置：files.refactoring.autoSave）。

限制哪些命令可以通过MarkdownString和在webviews中运行

Command links 在 MarkdownString 中是创建自定义交互的有用方式，可以在 VS Code 的悬停消息或 IntelliSense 详细信息中使用。Webviews 也可以使用命令链接直接从 webview 触发 VS Code 命令。然而，命令链接也可能很危险，因为它们可以用来执行任何命令，包括许多没有考虑安全性的命令。因此，命令链接默认是禁用的，必须由扩展明确启用。

虽然这种全有或全无的方法有效，但我们也发现它给扩展作者带来了太多的安全负担。需要使用命令链接的扩展必须验证它们渲染的内容中只包含安全的命令。这既容易忘记，也容易出错。

为了改进这一点，我们正在引入新的API用于命令链接启用，这些API允许扩展仅启用受信任的命令子集。

对于MarkdownString，isTrusted属性现在接受一个允许执行的命令列表（所有其他命令将被阻止）：

const md = new vscode.MarkdownString(
  `A command link: [Open setting](command:workbench.action.openSettings)`
);

// Set trusted commands instead of enabling all commands
md.isTrusted = { enabledCommands: ['workbench.action.openSettings'] };

对于webviews，WebviewOptions.enableCommandUris属性现在可以是一个启用的命令列表，而不仅仅是一个简单的true/false值：

const options: vscode.WebviewOptions = {
  enableCommandUris: ['workbench.action.openSettings']
};

我们强烈建议所有使用命令链接的扩展采用这个新的、更严格的API以提高安全性。

Webviews 和 webview 视图的一致来源

为了提高webviews的加载时间，我们现在尝试为给定类型的所有webview实例维护一个一致的来源。这有两个主要好处：

  • Webviews 可以更好地利用缓存。这意味着本地资源应该加载得更快。

  • Webviews 可以使用按来源分区的本地存储和其他 Web API。

    请记住，所有webview实例现在将在同一源上运行，因此如果它们使用诸如本地存储之类的API，请确保为每个资源分区任何特定于文档的数据/状态。例如，localStorage.setItem('scrollPosition', 100)将在所有webview实例中将scrollPosition设置为100。如果要为单个资源设置滚动位置，还需要在键中包含资源ID：localStorage.setItem(myDocUri, JSON.stringify({scrollPosition: 100 }))。

    您也绝不应使用localStorage或类似的API来存储关键数据，例如文档内容。虽然VS Code尽力为webviews维护一致的来源，但我们不能保证来源不会改变。

    在许多情况下，您应该使用webview 状态 API，因为这些 API 为您处理了上述两个问题。

每个扩展和类型的webview的源是随机生成的。相同的源在所有webview实例中使用。

目前，普通的webviews和webview views都试图保持一致的来源。我们计划在下一个迭代中为自定义编辑器和笔记本webviews采用这一点。

调试适配器协议

新的'startDebugging'反向请求

今天，VS Code 支持多个并发调试会话，但 调试适配器协议 (DAP) 仅涵盖单个会话。这意味着以编程方式创建新的调试会话不是 DAP 的一部分，只能在 DAP 或调试适配器之外完成，通常在包含调试适配器的调试扩展中完成。因此，非 VS Code DAP 客户端通常不容易获得诸如自动调试子进程等多会话功能，因为它们通常只使用调试适配器，而不使用 VS Code 特定的调试扩展。

为了改善这种情况，我们在DAP中添加了一个新的反向请求startDebugging，允许扩展从调试适配器内部创建一个新的调试会话（与调用者类型相同）。客户端能力supportsStartDebuggingRequest向调试适配器表明客户端支持startDebugging。

在十月份的发布中，VS Code 实现了 startDebugging。

提议的API

每个里程碑都伴随着新的提议API，扩展作者可以尝试它们。一如既往，我们希望得到您的反馈。以下是尝试提议API的步骤：

  1. 找到一个你想尝试的提案并将其名称添加到package.json#enabledApiProposals中。
  2. 使用最新的vscode-dts并运行vscode-dts dev。它会将相应的d.ts文件下载到您的工作区中。
  3. 您现在可以针对提案进行编程。

你不能发布使用提议API的扩展。在下一个版本中可能会有破坏性的更改，我们从不希望破坏现有的扩展。

静态笔记本预加载

新的notebookPreload提议的贡献点允许扩展贡献脚本，这些脚本被加载到特定类型的笔记本中。

{
    "contributes": {
        "notebookPreload": [
            {
                "type": "jupyter-notebook", // Type of notebook for the preload script
                "entrypoint": "./path/to/preload.js"
            }
        ]
    }
}

此贡献点由contribNotebookStaticPreloads API提案控制。扩展可以使用预加载在笔记本JavaScript环境中加载或定义全局变量。

预加载脚本必须是一个导出activate函数的JavaScript模块。所有预加载脚本在任何渲染器脚本之前都会被评估。

Notebook渲染器可以访问所有输出项

自定义笔记本渲染器现在可以访问其正在渲染的输出项的所有MIME数据。如果渲染器确定无法正确渲染主要输出项，此API提案允许它转而渲染其他MIME类型之一。

该提案的入口点是一个新的OutputItem._allOutputItems属性。该属性是当前输出项包含的所有MIME类型的有序列表。列表中的每个项都具有{ mime, getItem() }的形状。mime是MIME类型，例如text/html或image/png，而getItem()函数返回一个针对该MIME类型的OutputItem的承诺。

以下是渲染器如何使用这个新API的方法：

async function renderOutputItem(outputInfo, element, signal) {
  const didRender = tryRenderMainItem(outputInfo, element);

  if (!didRender) {
    // Fallback to render `text/html`
    const htmlItem = await outputInfo._allOutputItems
      .find(item => item.mime === 'text/html')
      ?.getItem();
    if (htmlItem) {
      // Here we can either render the 'text/html' item ourselves
      // or delegate to another renderer.
      const renderer = await ctx.getRenderer('vscode.builtin-renderer');
      if (renderer) {
        return renderer.renderOutputItem(htmlItem, element, signal);
      }
    }
  }
}

试试这个提案，让我们知道你的想法！

扩展遥测API

为了进一步推动遥测最佳实践并增强扩展提供的遥测功能，本次迭代引入了提议的telemetryLogger API。此API允许扩展提供一个TelemetryAppender，它充当核心发送逻辑（利用Application Insights或其他数据记录服务实现）。然后使用此TelemetryAppender实例化一个TelemetryLogger，这是您应通过其记录遥测的类。

TelemetryLogger 提供了一个共享的输出通道，用于查看发送的遥测事件、正确的遥测设置检查以及个人身份信息的清理。此外，使用 VS Code API 时抛出的任何错误都将记录到您的附加器中，以便更好地进行错误诊断。

在遥测示例中有一个简单的例子，您可以在问题 #160090中提供反馈。

日志输出通道

在最后一个里程碑中，我们介绍了LogOutputChannel API提案，用于创建一个仅用于日志记录的输出通道。在这个迭代中，我们向其中添加了logLevel属性和onDidChangeLogLevel事件。logLevel属性表示输出通道的当前日志级别，而onDidChangeLogLevel事件在输出通道的日志级别发生变化时触发。

/**
 * A channel for containing log output.
 */
export interface LogOutputChannel extends OutputChannel {

    /**
     * The current log level of the channel.
     * Defaults to application {@link env.logLevel application log level}.
     */
    readonly logLevel: LogLevel;

    /**
     * An {@link Event} which fires when the log level of the channel changes.
     */
    readonly onDidChangeLogLevel: Event<LogLevel>;
    ...
    ...
}

我们还向env命名空间添加了logLevel属性和onDidChangeLogLevel事件，以表示应用程序的当前日志级别，并在应用程序的日志级别更改时触发该事件。

export namespace env {
  /**
   * The current log level of the application.
   */
  export const logLevel: LogLevel;

  /**
   * An {@link Event} which fires when the log level of the application changes.
   */
  export const onDidChangeLogLevel: Event<LogLevel>;
}

工程

优化输入延迟

随着VS Code的规模增长，按键时的活动量也随之增加。在这个迭代中，我们退后一步，深入研究了在编辑器中键入时究竟发生了什么，以及我们可以推迟到按键在屏幕上渲染之后再进行哪些操作。这次探索的主要成果是：

  • 进行了多项更改，以尽可能推迟工作，直到在屏幕上渲染编辑器中的击键之后。粗略估计，当IntelliSense未显示时，输入延迟减少了约15%，而在重新过滤IntelliSense时，减少的幅度更大。
  • 我们现在有了更精细的技术，可以手动测量输入延迟并在亚毫秒级别进行优化。
  • 有一个正在进行中的更改，将帮助我们跟踪和报告输入延迟的样本。这将为我们提供一些具体的数字，以便维护和改进。

这只是这项工作的开始，我们还有更多的更改将在下一个版本中推出。

* 这些数字非常依赖于用于测试的硬件。在强大的硬件上0.5毫秒的改进，在更普通的硬件上可能最终是2毫秒。

自动渲染器性能分析

VS Code 的渲染进程负责其用户界面；它确保光标闪烁、能够输入和保存。渲染进程中的任何性能问题都会对用户可见，并导致不良体验。为了帮助我们识别和修复渲染进程中的性能问题，我们添加了一个新的设置 application.experimental.rendererProfiling，该设置可用于自动分析渲染进程。该设置可以设置为 on 以启用分析，设置为 off 以禁用分析。启用后，每当渲染进程“看起来有压力”时，它将被分析几秒钟，然后对分析结果进行分析、匿名化并发送以供检查。您可以使用窗口日志来跟踪分析过程。

请注意，此功能目前默认关闭，因为我们仍在学习和调整。请尝试使用并告诉我们您的想法。

Windows 11 上下文菜单

在此版本中，VS Code 安装程序默认情况下会为 Windows 11 上下文菜单 添加一个 使用 Code - Insiders 打开 的上下文菜单项。对于之前在安装 Insiders 时选择加入上下文菜单的用户，更新到最新的 Insiders 后，旧样式菜单中的 Shift + F10 项将被替换为新的项。对于其他用户，您需要重新安装 Insiders 并在安装向导中选择加入以启用此菜单项。由于我们在开发此菜单项时遇到的问题，我们计划将此功能限制在 Insiders 版本中几个里程碑，以在将其推送给所有 Windows 11 用户的稳定版本之前获得信心。

VS Code 安装对话框，带有添加使用 Code - Insiders 操作的选项

然后，使用Code Insiders打开操作将在Windows文件资源管理器的文件夹和文件上下文菜单中可用。

Windows 11 文件夹上下文菜单

显著的修复

  • 151019 调试悬停时隐藏
  • 153852 提案：移除ES5类兼容性以加速扩展API
  • 156104 如果已经静态转发，不要在点击URL链接时自动转发端口
  • 158921 设置在其他地方修改的指示器悬停内容溢出

感谢您

最后但同样重要的是，向VS Code的贡献者们表示衷心的感谢。

问题跟踪

对我们问题跟踪的贡献：

对 vscode 的贡献：

对 vscode-pull-request-github 的贡献：

对vscode-dev-chrome-launcher的贡献：