Blink.cmp 补全引擎中缓冲区匹配项的显示控制技巧

缓冲区补全与LSP补全的优先级问题

在使用Blink.cmp补全引擎时，开发者可能会遇到一个常见现象：当同时存在LSP提供的补全项和缓冲区中的文本匹配项时，默认情况下引擎会优先显示LSP的补全建议，而隐藏缓冲区的文本匹配。这一设计旨在避免重复的补全建议，因为LSP通常已经包含了项目范围内的符号信息。

问题重现场景

假设在HTML文件中编辑时：

1. 缓冲区已有单词"application"
2. 开始输入"app"时
3. 只显示来自emmet LSP的"applet"建议
4. 需要输入到"appl"才会显示"application"

这种行为可能会让习惯看到所有可能补全项的用户感到困惑，特别是当LSP提供的建议并非总是最相关时。

配置解决方案

Blink.cmp提供了灵活的配置选项来控制这一行为：

1. 完全显示缓冲区补全：通过设置sources.providers.lsp.fallbacks = {}可以强制始终显示缓冲区源的建议，无论是否有LSP建议存在。

2. 智能回退机制：默认配置中的fallbacks = { 'buffer' }实现了智能回退，当LSP没有返回有效建议时才会显示缓冲区补全。

3. 基于类型的过滤：引擎会忽略LSP返回的类型为Text的项(通常由lua_ls提供)，因为这些通常与缓冲区源提供的重复。不同LSP服务器可能使用不同的类型标记，例如pyright可能使用其他类型标记缓冲区项。

高级定制建议

对于希望更精细控制补全行为的用户，可以考虑：

1. 按文件类型配置：针对特定文件类型(如HTML)调整fallbacks设置，因为不同语言的LSP行为差异较大。

2. 优先级调整：通过修改源优先级，可以影响补全项的排序而不完全隐藏某些源。

3. 自定义过滤逻辑：高级用户可以编写自定义函数来处理LSP返回的结果，实现更复杂的显示逻辑。

设计哲学理解

Blink.cmp的这种默认行为体现了几个设计考量：

• 避免信息过载，减少不相关建议
• 尊重LSP作为主要信息来源的权威性
• 提供escape hatch让用户可以根据需要调整

理解这些设计原则有助于用户更好地配置和使用该补全引擎，在保持高效编码体验的同时获得所需的补全建议。