Daniel Shahaf wrote:
Branko Čibej wrote on Thu, Nov 07, 2019 at 17:28:35 +0100:
Not with a new option. Instead --show-item should accept a
comma-separated list of keywords.

You mean, like this?

It's tempting to say +1, commit it, and say we've made an improvement. I have been missing the ability to specify multiple arguments to --show-item, and it scratches that itch.

But I do have some reservations and further thoughts.

I feel sad about how inconsistent our output formats are. Subcommands such as "status" and "list" are formatted mainly using fixed-width columns, "info" and "log" mainly using separate lines, then there are the XML variants, and now a tab-delimited output. And, in all of these except XML, no consistent escaping of values for machine readability. We have said the outputs (except XML) simply are not intended to be parsed. That is fine as far as it goes, but leaves something lacking.

Tab-separated output seems a rather arbitrary addition to the flock, though it's an OK choice in isolation for this particular use.

Better consistency with other subcommands would be achieved by using space-separated output with field widths chosen per field, like we chose them for "status" and "list". Or item-per-line format like the original "info" output. Why should selecting items not be orthogonal to the output format?

The XML output should also support --show-item. It's arbitrarily inconsistent that it presently doesn't. Element names used in XML should match those in show-item; compatibility is harder to achieve for that, because we already made them different.

These days, JSON would be a reasonable choice of output format as an alternative to XML. Consider if we offered it, how would we select it? Perhaps a --json flag? Then why not a --tsv flag for TSV format, and expect that too to be made available to other subcommands?

We might want to allow using multiple options, like "--show-item=revision --show-item=kind" in addition to comma-separated values.

- Julian

Reply via email to