Could you just feed the output of text/template into text/tabwriter?

From the perspective of providing useful template functions to users to simply format output without writing or installing another tool, that doesn't seem like a very useful approach. Both the Docker CLI and GitHub CLI (and likely many other tools accepting go templates) provide a templating. Seems making text/tabwriter available via this mechanism would be generally useful to provide tidy output to the console.

While I realize this proposal as written may not be acceptable because it emits formatted text directly instead of facilitating formatting, perhaps it would be better to consider alternatives that still provide the core formatting to functions.

For instance, if we were to try to do this in a function, something like this could work:

{{range .Nodes}}{{tableRow .Id .Name}}{{end}}

However, we lose any ability to pass fields to other custom functions. Perhaps we could consider something like this where parenthesis are parsed by the text/template engine:

{{range .Nodes}}{{tableRow (.Id | color "green") .Name}}{{end}}

Here, {{.Id}} would be passed to the custom color function before the resulting string is passed to the custom tableRow function.

I see you can already use parenthesis like that: cli/cli#3488 (comment)

While I'm tempted to just close this proposal out, I would like to still see if there's interest in it. While I have a solution (or workaround at least), I think this could still be useful, though I realize it might be out of scope since it would emit formatted text itself instead of merely facilitating in formatting.

I'm not suggesting installing another tool, I'm suggesting something like (untested)

func TemplateTable(tmpl *template.Template, w io.Writer) error {
    var tabw tabwriter.Writer
    tabw.Init(w, ...)
    tmpl.Execute(&tabw, ...)
}

Ah, I see. That's clever and if a table format was all we wanted to support I agree that's very straight forward. In this case, I'm sure the CLI works want to keep the format open-ended.

This is a very specific instance of a general request to be able to pipe a block of template output through another function. If we could do that, then "table" could be defined as a function outside the template package. But that's not possible today.

I was able to devise a way: cli/cli#3488

Originally I used text/tabwriter, but after feedback switched over to the TablePrinter the GitHub CLI already used internally. I ended up adding just a row function since declaring and ending a table wasn't really necessary. It works with range like so:

{{range .}}{{row (printf "#%v" .id | autocolor "green") .title}}{{end}}

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

I'd love to contribute my work (the original work using tabwriter, perhaps, though some refactorings for performance would be good) if approved. That said, would it be appropriate to pile on a few other related ideas or better as a separate proposal? Specifically, supporting "safe navigation operators" (a proposal to golang itself that was rejected) for templates since you have a limited grammar. For example, if I query for a nested string, there's no way short of duplicating parts of templates between if/else/end to handle the inevitable error. For example, GitHub can send back status { message } as a leaf node, but if status is nil, .status.message errs. The built-in and and or functions evaluate (or, rather, they are evaluated before being passed to those functions) all operands so those don't work either. Instead, perhaps supporting .status?.message would be ideal. The parameter would have to be an interface{}, or perhaps the grammar extended to something like .status?.message || "".

(Was also posted for discussion to https://forum.golangbridge.org/t/support-for-safe-navigation-in-text-templates/23325)

The bar for adding new things to template is pretty high.
The table concept here is probably not clearing that bar.

/cc @robpike

I agree that this does not bring enough new power to the library to be worth the change.

Understood. I can open a separate issue for the safe navigation operator, but wondering if you think that also wouldn't right to the bar given my use case above. If it's at least worth discussing in a separate issue, I'm happy to open one.

I believe "safe navigation" is #43608

No change in consensus, so declined.
— rsc for the proposal review group