Feature: Allow non-formatted data table in final log

[plocket]

Our data table has some very long strings in it. The final log tries to make all the columns line up. That combination makes the whole table quite a lot longer than it needs to be. We'd prefer that the log not attempt to make the table columns all the same width.

[aslakhellesoy]

I think I understand the problem. I have an idea for a different feature that I think would address your problem, and also preserve readability.

We trim the values of long cells. The cell width can be computed by querying the terminal's width. Alternatively you could supply one with CUCUMBER_MAX_CELL_WIDTH=number

Would that work for you?

[plocket]

Those options sound good in some cases, but in our cases I suspect we'd sometimes want to see the full contents of each cell. We just wouldn't want every cell to need to have the same width.

[plocket]

My second post apparently did not post:

On second thought, maybe I'm making assumptions. The option you suggested would require a couple extra steps when trying to troubleshoot a problem (scroll through to find which file and test was run and then look up the test itself in its file), but maybe it wouldn't be that big of a burden. Or maybe it would. It probably just needs some user testing.

I do think there would need to be some indicator in a cell when its input did get truncated.

[aslakhellesoy]

How about this then:

• CUCUMBER_TEXT_OVERFLOW which can take any value. If the value is ellipsis, use the … character, if it is clip, just clip it. Otherwise, use the value itself. Inspired from CSS' text-overflow
• CUCUMBER_TABLE_UNFORMATTED which would disable table cell alignment if the env var has a truthy value.

Would you be interested in submitting a pull request for this @plocket?

[plocket]

Both sound good. Great CSS inspiration. No need for a custom cell size unless someone asks for it - I'm sure that can be hard-coded at first. Do they have to be env vars or can they get passed in as options? Would allow more flexibility with the names.

CUCUMBER_TEXT_OVERFLOW alternative names depending on type of var: CUCUMBER_TABLE_OVERFLOW, TABLE_OVERFLOW, table_overflow

CUCUMBER_TABLE_UNFORMATTED alternative names depending on type of var: CUCUMBER_UNFORMATTED_TABLE, unformatted_table, remove_table_formatting, cell_fit_content, table_fit_content, equal_table_cell_width (which would be the opposite).

As for me coding it up, I think it may be over my head. I'm not very experienced and I don't have a ton of bandwidth. If you don't mind my asking a ton of questions to take some of that load off, that would be more doable, but then it probably wouldn't help the team that much.

Looking at cli-table3, a reasonable mvp might be to allow the dev to set the column width directly.

[aslakhellesoy]

Happy to answer any questions if you or anyone else want to take a stab at it.

[davidjgoss]

To be clear when we talk about the "final log" do we mean the summary (default) formatter?

If so we could lean on the --format-options mechanism rather than introducing new flags or env variables. Other formatters could then also use (or ignore) these cues for formatting.