Mechanism for passing arbitrary extra config to formatters

[dbarnett]

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.

[artasparks]

How about allowing to configure executables to be arbitrary commands? That's what I did with google-java, since there was no other way: https://github.com/google/vim-codefmt/blob/master/autoload/codefmt/googlejava.vim

Then you don't need infinite configuration -- the user just overwrites the command (rather than an executable)

[artasparks]

I see: this issue is more about having multiple configurations when you have to work across many different repos?

[dbarnett]

Yeah, per-path config is one concern (particularly w/ the --aosp example), and I have a few other minor concerns: they might need to override flags we're passing by default (like --type in the example above), and shell escaping gets weird (which you worked around for google-java-format, I guess).