Markdown 支持是我在 2016 年加入 Visual Studio Code 时拥有的第一个功能。这些年来，增加 VS Code 的内置 Markdown 支持是非常有益的，也可以看到我们的 Markdown 扩展如何直接和间接地塑造核心功能，比如 webviews 和 notebooks。在这里，我很高兴分享一个我在过去半年里一直在默默努力的项目，代表着 VS Code 的 Markdown 工具下一步：Markdown 语言服务器。有了这个语言服务器，我们可以将 VS Code 的大部分内置 Markdown 语言工具——从文档大纲、智能折叠到路径补全——都提供给其他编辑器和工具。
Markdown 语言服务器的工作分为两个新的开源库：
- Markdown 语言服务 - 一个 TypeScript 库，提供使用 Markdown 的工具
- Markdown 语言服务器 - 使用语言服务构建的 Markdown 语言服务器
虽然这些库仍处于早期阶段，但它们已经被 VS Code 1.70+ 使用。我们还看到了这种切换的一些好处，例如将 Markdown 工具移动到一个单独的进程中，这样它就不会阻碍其他扩展。
到这里，也许你想问：为什么需要 Markdown 语言服务器？老实说，我花了这六年的时间才意识到这一点。从将 Markdown 简单地视为带有一些星号、括号和井号的纯文本，到将 Markdown 理解为一种标记语言，并且可以从我们发布的许多相同工具中受益用于 TypeScript 或 Python 等编程语言。
Markdown 语言功能集现包括：
- 文件大纲
- 工作区符号
- 文档链接
- 智能折叠
- 智能选择
- 完成
- 改名
- 查找所有参考资料
- 转到定义
- 断开链接的诊断
- 更新文件移动/重命名的链接
我知道这些新工具会让使用 Markdown 更快、更安全。但是当我回顾这个编程语言的通用特性列表时，一个想法一直困扰着我。几个月前我认为它很荒谬，但现在当我再次考虑时，我意识到可能终于到了 Markdown 语言服务器的时候了。
Are you being servered?
首先是一个相当普通的问题：我发现有效地为 Markdown 文件实现链接诊断非常具有挑战性。在大型 Markdown 工作区（例如 vscode-docs）上，我一直在不经意间阻碍扩展主机几百毫秒，这很不好。另一方面，语言服务器在作为自己的进程运行。不仅如此，语言服务器现在还有一个新的诊断拉取模型。
当然还有更崇高的理由。例如，Markdown 语言服务器对其他编辑器和工具很有用。这包括 VS Code 团队发布的另一个编辑器：Monaco，更不用说诸如 Markdown CLI 工具之类的可能性了。如果我自己没有时间构建这样的工具，也许其他人可以使用语言服务器作为起点。通过提供一个新的语言服务器，我或许还可以围绕改进 Markdown 工具展开共同的努力。与每个编辑器/工具重复努力实现自己的 Markdown 支持不同，语言服务器可以将开发人员聚集在一起，共同开展一个让所有人受益的更大项目。
在进行了所有重构之后，将代码移动到语言服务器也将是一项繁重的工作，但我意识到不必一口气做完所有事情，可以增量构建服务器，一次将一个功能从 VS Code Markdown 扩展转移到新的 Markdown 语言服务器。理想情况下，用户永远不会注意到某个功能何时从扩展程序移动到语言服务器。一次移动一个语言功能，一边学习一边前进，并在明确需要时进行重构。诊断是最后一个要迁移的功能，因为我不仅将它们移动到语言服务器，而且还重写了它们以使用语言服务器的新拉取诊断模型。整个工作的最后一次提交主要从 Markdown 扩展中删除了现在未使用的代码。所以今天如果你使用的是 VS Code 1.70+，几乎所有 Markdown 语言功能都使用新的语言服务器。
一起构建更好的 Markdown 工具
Markdown 语言服务器真正让我兴奋的是，现在这个项目比 VS Code更大。通过让我们的 Markdown 工具易于使用，我希望我们可以帮助所有人推动 Markdown 工具的发展。这些开源项目是帮助共同构建 Markdown 工具未来的邀请。如果您有兴趣做出贡献，请查看新项目，看看您可以使用它们创建什么。您可以提交错误报告和功能请求，也可以提交 PR。让我们一起建造它们！
如果您有兴趣查看源代码或贡献代码，可以在 GitHub上找到 Markdown 语言服务和服务器。
原文较长，如感兴趣点击阅读原博客，欢迎前往VS Code 主页！
关注微软开发者MSDN，了解更多
相关文章
