Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Mechanism for passing arbitrary extra config to formatters

未关闭
#66 3 条评论 3 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
vim
领域
tooling

调研方向

该 issue 将 .clang-format 和 .editorconfig 列为可能的项目本地配置源，并以 js-beautify 的 --type 和 --aosp 为例。首先梳理当前如何选择 formatter 专用选项；完成的标准是确定一种按 formatter 和按路径的机制，避免相互冲突的 defaults 和意外传播。

由索引模型根据 Issue 内容生成。

描述

enhancement

Lots of formatters have extra config users may want to pass, and creating a top-level flag for each one will get cumbersome. We should consider a generic mechanism for passing flags through to formatters.

Factors to consider:

  • These should be attached to the fine-grained formatter name, not the language, because we don't want to accidentally pass them to a different formatter that doesn't support them when the user switches formatter.
  • Some might conflict with default flags. For instance, a user might want to pass --type to js-beautify and find that it conflicts with the --type flag we already pass by default.
  • Most config would be per-path rather than global preferences. For instance, a user will want to configure an --aosp flag when working on Android Java, but then be surprised if it's applied to other Java code they're working on later.
  • If possible, these config options should live in some project-local config file like .clang-format or .editorconfig, not something codefmt-specific, and codefmt should just try to be smart about detecting and not conflicting with such config where appropriate.
主要语言
Vim Script
星标
1.1k
派生
102
30 天内没有已合并 PR

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

google/vim-codefmt 的其他 Issue

查看 google/vim-codefmt 的全部 Issue

相似的 Issue

更多 DevTools Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。