Problem
The --custom flag uses an ad-hoc mini-language with two layers of delimiter-based parsing:
stringList.Set splits the flag value on ,
customListToTableRenderDef then splits each item on :
Relevant code:
cmd/rendertree/impl/impl.go:218-225
cmd/rendertree/impl/impl.go:551-594
This means some otherwise valid Go template expressions cannot be represented on the command line, especially when a column name or template needs a literal , or :.
Why this matters
--custom is documented in the README as a supported way to define custom columns, but the current format is much more fragile than --custom-file.
Examples that are awkward or impossible today:
- string literals containing
: or ,
- templates that want to emit those characters literally
- future extensions that need additional structured fields without making the grammar even more ambiguous
Expected behavior
The CLI should provide one of these:
- A structured repeatable flag format that does not depend on raw
, and : splitting.
- Escaping/quoting rules for the current mini-language.
- A clear deprecation path for
--custom in favor of --custom-file.
Suggested direction
I would prefer deprecating --custom and steering users toward --custom-file, unless there is a strong need to keep the inline syntax.
If --custom stays, it should become a repeatable structured flag rather than a hand-rolled CSV-like grammar.
Problem
The
--customflag uses an ad-hoc mini-language with two layers of delimiter-based parsing:stringList.Setsplits the flag value on,customListToTableRenderDefthen splits each item on:Relevant code:
cmd/rendertree/impl/impl.go:218-225cmd/rendertree/impl/impl.go:551-594This means some otherwise valid Go template expressions cannot be represented on the command line, especially when a column name or template needs a literal
,or:.Why this matters
--customis documented in the README as a supported way to define custom columns, but the current format is much more fragile than--custom-file.Examples that are awkward or impossible today:
:or,Expected behavior
The CLI should provide one of these:
,and:splitting.--customin favor of--custom-file.Suggested direction
I would prefer deprecating
--customand steering users toward--custom-file, unless there is a strong need to keep the inline syntax.If
--customstays, it should become a repeatable structured flag rather than a hand-rolled CSV-like grammar.