共计 1814 个字符，预计需要花费 5 分钟才能阅读完成。
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，理解更多