OK, thanks. Yeah, that backwards compatibility stipulation is a bit rough in this case but makes sense. Your patch does mean that you could potentially use different separators for each key which might be useful. The other nice thing about your patch is you'll be able to easily apply different colors to each key if desired so that's a nice win too.
For the moment, in case it helps, I ended up crafting a Bash function for local use that looks like this;
----- SNIPPET-----
# Label: Git Tag List
# Description: List tags in tabular form.
gtl() {
local format="\
%(color:yellow)%(refname:short)%(color:reset)|%(taggerdate:short)\
|%(color:blue)%(color:bold)%(taggername)%(color:reset)|%(subject)\
|%(color:green)%(trailers:key=Commits,key=Files,key=Deletions,\
key=Insertions,key=Duration,separator=|)%(color:reset)"
git tag --list --color --format="$format" | column -s "|" -t
}
----- SNIPPET-----
This allows me to list all the keys I need and use a pipe as a separator for column formatting. I think that's quite nice while not making the format string anymore complex than it needs to be.
> On Sep 9, 2024, at 5:03 PM, Jeff King <peff@xxxxxxxx> wrote:
>
> On Fri, Sep 06, 2024 at 05:09:08PM -0600, Brooke Kuhlmann wrote:
>
>> Use of a custom separator is a nifty trick. Thanks. A little
>> unintuitive but works. Definitely would be neat if you patch this to
>> work without the custom separator, though.
>
> The separator will always be required (even if you use multiple
> %(trailer) blocks), because it overrides the default of terminating with
> a newline. And we can't switch that default without breaking
> compatibility for existing users.
>
> So I think after my series you'll have:
>
> %(trailers:key=Files,separator=) %(trailers:key=Duration,separator=)
>
> or similar.
>
> -Peff
