LSP-Bridge项目中的文本保存事件处理机制优化

在LSP-Bridge项目中，最近修复了一个关于文本保存事件(didSave)处理的逻辑问题。这个问题涉及到语言服务器协议(LSP)中文本同步机制的实现细节。

LSP协议规定，客户端应该在文档保存时向服务器发送didSave通知。根据协议规范，这个通知的发送应该基于服务器的textDocumentSync.save能力，而不是textDocumentSync/willSave能力。之前的实现错误地依赖了willSave能力来判断是否发送didSave通知。

这个问题的具体表现是，在使用rust-analyzer语言服务器时，由于该服务器没有设置willSave能力，导致LSP-Bridge从不发送didSave通知。这进而影响了诊断信息的更新，因为许多语言服务器依赖保存事件来触发完整的代码分析。

在LSP协议中，文本同步(textDocumentSync)是一个核心机制，它定义了客户端和服务器之间如何同步文档状态。这个机制包含几个不同的选项：

1. open/close通知：处理文档打开和关闭事件
2. change通知：处理文档内容变更
3. willSave/willSaveWaitUntil：在保存前触发
4. save通知：处理保存完成事件

这些选项都是独立的，服务器可以选择支持其中的部分或全部。客户端应该根据服务器实际声明支持的能力来决定发送哪些通知。

修复后的实现现在正确地检查textDocumentSync.save能力来决定是否发送didSave通知。这个改动确保了与LSP协议规范的一致性，也解决了rust-analyzer等语言服务器的兼容性问题。

对于开发者来说，理解LSP中这些同步机制的区别很重要：

• willSave是在保存前触发，通常用于在保存前执行某些操作
• didSave是在保存完成后触发，通常用于触发完整的代码分析
• 两者是独立的，服务器可能只支持其中一个

这个修复展示了协议实现中细节的重要性，即使是看似微小的逻辑差异，也可能导致与特定语言服务器的兼容性问题。通过严格遵循协议规范，可以确保与各种语言服务器的良好互操作性。