Open mikaelstaldal opened 8 months ago
CSV output seems like it would make sense for normally wrapped plain text, but what about tables with cells that span rows or columns, or cells that contain nested widgets or even just preformatted multi-line text (which is the default)?
I'm not opposed to a feature like this, but I'm not sure what it would look like in the general case.
Right, CSV output might be tricky in the general case. Maybe only support for "simple" tables?
But what about supporting infinite width, and using that by default on non-interactive output? That would be a quick win.
I'm running into a similar problem, though not limited to tables, for output in (Jenkins) CI logs. Any line is unnecessarily truncated at column 79.
I wonder whether it generally would be feasible to set the terminal width to "unlimited" as soon as some CI-related environment variables, like in my case CI
and JENKINS_HOME
, are set? Because in such scenarios output is usually redirected to (log) files.
I agree that we need a way to use a different width on non-interactive output.
unnecessarily truncated at column 79
In the meantime, you might use NORMAL
or PRE_WRAP
whitespace if you prefer wrapping over truncation.
Wrapping columns is not really an option for me, since my tables contains several long strings (e.g. URLs and IDs encoded as hex).
Tables are rendered poorly on non-interactive output (e.g. redirect to file). The default width of 79 causes unwanted truncation of content.
It would be nice to be able to set "infinite" width for tables, so that they expand to fit all content in every cell. Or even better an option to render tables as CSV, JSON or some such format. That would be useful when redirecting to file or process for machine parsing.
I would like to be able to use the same Table API for both nice looking human-readable tables for interactive output, and for machine-readable format for non-interactive output.