fix typo in matklad_why_lsp

kirraObj · Apr 4, 2024 · f833f21 · f833f21
1 parent 9cc8a04
commit f833f21
Showing 1 changed file with 1 addition and 1 deletion.
diff --git a/content/matklad_why_lsp/index.md b/content/matklad_why_lsp/index.md
@@ -118,7 +118,7 @@ interface CompletionItemProvider {
 
 请关注 VSCode 的架构设计。虽然 Electron 带来的用户体验有待商榷，但其内部架构却蕴含着深刻的见解。编辑器 API 应该围绕着与表现形式无关的高级特性来设计。基本的 IDE 功能应当成为易于扩展的一级功能，而不是每个插件作者都需要重新发明的轮子。尤其是辅助功能、代码操作和高亮提示应该被当作核心的用户体验元素。这代表了 IDE 界的一个重大的用户体验创新，虽然这个想法已经不新鲜，但让它成为所有编辑器界面的标准配置是非常必要的。
 
-但不要把 LSP 作为一级概念。尽管这可能听起来有些出乎意料，但 VSCode 实际上并不直接处理 LSP。它仅提供了一系列接口，而不关心这些接口是如何实现的。比如在实际运行中，VSCode 中的 Rust 和 C++ 扩展并不会共用一套语言服务协议（LSP）实现，而是各自在内存中保留了独立的 LSP 库副本！
+但不要把 LSP 作为一级概念。尽管这可能听起来有些出乎意料，但 VSCode 实际上并不直接处理 LSP。它仅提供了一系列接口，而不关心这些接口是如何实现的。比如在实际运行中，VSCode 中的 Rust 和 C++ 扩展并不会共用一套 LSP 实现，而是各自在内存中保留了独立的 LSP 库副本！
 
 我们还应该充分利用开源社区的力量，避免将所有 LSP 实现集中管理。应鼓励不同的开发团队独立地优化编辑器对于 Go、Rust 等语言的支持。VSCode 已经展示了一种可能的路径，通过其市场和一个去中心化、独立插件的体系。然而，理论上，如果各种编程语言都有各自的独立维护者团队，那么采用单一共享的代码仓库或源代码树的工作模式也是可行的。