Question

有人通过contributes.languages贡献点为多个扩展名提供相同语言的语言配置文件时，是否有人知道VSCode的行为？

我只是想在扩展程序中的一种语言中添加自动关闭对，但是，至少还有一个其他活动扩展名（我插件的每个用户也可能有）提供了自己的扩展名配置该语言。

是一个还是另一个？如果是这样，基于什么？ The docs suggest multiple configs are OK，因为它说贡献点也可以作为“丰富” VSCode语言知识的一种方式，但是我似乎无法获得扩展名来添加自动闭合对。

我确定我使用的是正确的语言ID（配置此语言的其他扩展使用的ID）以及扩展。

如果只允许我扩展语言的配置，我是否应该仅在language-configuration.json文件中提供所需的信息？例如：

{
    "autoClosingPairs": [
        { "open": "/**", "close": " */", "notIn": ["string"] }
    ]
}

如果所有这些都有意义，并且贡献不起作用，那么有人对调试问题有任何建议吗？预先感谢。

Answer 1

好吧，如果其他任何人碰巧都在为此苦苦挣扎（不太可能得到这个问题的关注：）哦，好吧。），您的问题可能是{{1 }}清单。

在吸管了几天之后，我终于开始尝试一些毫无意义的东西，似乎对此没有影响。因此，我开始从publisher中删除与VSCode扩展相关的键，并且很确定，当我到达package.json时，瞧！我的语言配置终于有了。

我最初关于“为什么？”的假设是，vscode在幕后按字母顺序注册了扩展名，而另一个扩展名的发布者可能早于我的发布者名称。但是，a，我的发布者名称为package.json，竞争性扩展程序的发布者名称（也配置了相关语言）为publisher，因此有了这个假设。此外，当我决定更改发布者名称以查看发生了什么情况时，我选择了dubs-dev-extensions，这也起作用（因此，它没有发布者密钥，并且使用了新的发布者名称）。 salesforce和peter-weinberg都在peter-weinberg之前，因此按字母顺序排列的不是答案。在撰写本文时，我很沮丧，并且将尝试向vscode报告一个错误，如果不是，至少，我希望能对我为何经历这种奇怪行为有所解释。

VSCode扩展中的竞争语言配置

1 个答案: