Open yanone opened 5 months ago
I'd suggest we use the same flag for this, adopting a syntax similar to URL fragments.
So, for only emitting the log messages with the "width" code on com.google.fonts/check/legacy_accents one would invoke fontbakery with -c com.google.fonts/check/legacy_accents#width
Shortcuts should also still work, so one could also use -c legacy_accents#width
In that case, it would match any check containing "legacy_accents" in its ID and only show messages with code-word containing "width" (or should it perhaps only match exact codes?)
What do you think?
Note: On my example above I talk about a "width" code, but that legacy accents check actually has codes called "legacy-accents-width" and "legacy-accents-gdef", which I think are redundant names. I'd suggest updating that check to have simpler, less redundant message codes.
What do you think?
Sure, that would work. The precise interface used is up to you. Just make sure that, especially if you want to use the same interface, that partial matches to codes are allowed just as partial matches to check names are allowed, so not matching exact codes. If I want to match an exact code, I will supply the full code as an argument. If then there's still another code that's even longer and contains my target code, that would be very rare and I can live with that tradeoff.
We can run only specific checks with the
-c
option.Additionally, I'm proposing a CLI argument to filter output by specific codes emitted.
This is particularly useful for development, for instance checking the entire GF library for a specific issue in development. Since checks can emit messages with several different codes, it's currently not possible to limit the output to a particular code that I'm currently working on.
I would want to combine checks filter and the output filter to precisely target my field of development.