Coc.nvim 实现类似 VSCode 的编辑器默认格式化器配置

在代码编辑器的使用过程中，格式化工具的选择往往因项目而异。以 Python 为例，开发者可能会根据项目需求在 autopep8、black、isort 或 ruff 等不同格式化工具之间切换。Coc.nvim 社区近期针对这一需求进行了深入讨论和技术实现，最终通过新增配置项解决了多格式化器优先级管理的问题。

问题背景

当前 Coc.nvim 生态中存在两种主要的格式化器管理方案：

1. 单一扩展集成多个格式化器：如 coc-pyright 扩展内置了对多种 Python 格式化器的支持，用户通过扩展特定配置进行切换。这种方案的局限性在于扩展需要维护所有可能的格式化器实现，这在实践中往往难以持续。

2. 优先级配置方案：如 coc-prettier 扩展通过设置优先级数值来调整格式化器的执行顺序。这种方式对于支持多文件类型的扩展（如同时处理 JavaScript 和 JSON 的扩展）存在明显不足，很难为所有场景找到统一的优先级数值。

技术方案

受 VSCode 的 editor.defaultFormatter 配置启发，Coc.nvim 社区提出了新的解决方案。该方案的核心是在语言作用域内指定默认格式化器扩展，通过以下方式实现：

1. 新增 coc.preferences.formatterExtension 配置项，支持按语言类型覆盖
2. 在扩展注册格式化提供者时记录扩展名称
3. 执行格式化操作时优先使用指定扩展的格式化器

实现细节

技术实现面临的主要挑战是如何在扩展激活时获取当前扩展的上下文信息。由于 Coc.nvim 的架构与 VSCode 不同，无法直接获取扩展上下文。最终解决方案是：

1. 利用 parseExtensionName() 工具函数从调用栈信息中解析扩展名
2. 将扩展名与格式化提供者关联存储
3. 在执行格式化时根据配置选择对应的提供者

使用示例

配置示例展示了如何为不同文件类型指定不同的格式化器：

{
    "[typescript]": {
        "coc.preferences.formatterExtension": "coc-biome"
    },
    "[markdown]": {
        "coc.preferences.formatterExtension": "coc-diagnostic"
    },
    "diagnostic-languageserver.formatFiletypes": {
        "markdown": "prettier"
    }
}

方案优势

这一解决方案具有以下显著优点：

1. 解耦了格式化器实现与选择逻辑，各扩展只需关注自己的格式化功能
2. 支持细粒度的文件类型级别配置，满足复杂项目的多样化需求
3. 保持了与现有生态的兼容性，无需修改现有扩展即可使用
4. 配置方式直观，与 VSCode 用户的使用习惯一致

总结

Coc.nvim 通过引入类似 VSCode 的默认格式化器配置机制，有效解决了多格式化器环境下的优先级管理问题。这一改进不仅提升了编辑器的灵活性，也为后续的生态扩展奠定了良好基础。对于需要同时处理多种语言或项目规范的用户来说，这一功能将显著改善开发体验。