allow to flexibly change the display width limit

[bkamins]

Fixes #2389

I made it a bit different than Markdown rendering, but I think we do not have to be super cautious here as this is just handling corner cases of display.

Also fixes the problem of overwide first column (not as nicely as PrettyTabes.jl but again - this is a rare corner case now as we are trimming at 32 screen width anyway)

CC @nalimilan @ronisbr

[bkamins]

In the process I have noticed that we did an incorrect escaping of CSV and TSV output. I have fixed it. One debatable thing is what we should use in CSV/TSV for non-standard types (like Symbol, Char - in the tests, or e.g. Date) - should we use print or repr to show them. I opted for repr now (as it kind-of retains type information), but maybe print would be preferred. Comments are welcome here.

[bkamins]

@nalimilan - tests will fail now. I will clean them when we decide if we want to use repr or print in CSV/TSV output.

A a comment - I thought of repr as print is used in CSV.jl, so here we could provide a more low-level output. Probably this CSV/TSV feature is not used much (if at all - given it had escaping bug no one reported) so we could make it have a different behavior than CSV.jl.

[nalimilan]

I'd prefer using print, as it gives something which is more likely to be usable and parseable. Even reading back a date into Julia will work better using print.

Regarding truncation, I've just checked, and dplyr only truncates when the output would be wider than the screen. Maybe we should do that too? One use case I can imagine is a column with short texts and one or two columns with variables describing them.

[nalimilan]

Is it really approximate? AFAICT, you stop at 32 and take the previous character, so it's always the maximum width before going beyond 32, right?

[bkamins]

No, because some characters have more than 1 text width (in which case we can get a bit different result)

[nalimilan]

Yes but since you return the last character before going beyond 32, the result will always be less than 32, right? I think it would be worth mentioning in the docstring rather than just saying it's approximate.

[bkamins]

The precise statement is that the result without … has maximal text width less or equal than 32 display characters, but how would you phrase it so that this would be readable?

[nalimilan]

Maybe something like this? Anyway that's internal, what matters is that it's correct even if it's not super easy to read. :-)

`truncstring` indicates the maximal width the output can use before being truncated
(in the `textwidth` sense, excluding `…`).

[bkamins]

OK - I have proposed something along these lines 😄

[bkamins]

I'd prefer using print

OK - I switch to print.

Maybe we should do that too?

If you try to do this it quickly starts to be very messy, it was tried in #2087.
Actually even in your scenario I would prefer truncating (32 characters usually will be enough to get an understanding what is inside a string)

Also soon we will have a PrettyTables.jl backend to choose from that does what you propose (but it has a different design in general) - so someone will be able to go for that backend if needed.

[nalimilan]

If you try to do this it quickly starts to be very messy, it was tried in #2087.
Actually even in your scenario I would prefer truncating (32 characters usually will be enough to get an understanding what is inside a string)

Also soon we will have a PrettyTables.jl backend to choose from that does what you propose (but it has a different design in general) - so someone will be able to go for that backend if needed.

In the use case I have in mind, you have unique texts that you may want to read, so just having an idea of the contents isn't enough. But yeah it's difficult to handle this well in all cases. It's nice if PrettyTables aims to fill this gap.

[bkamins]

I am changing the implementation to add truncate keyword argument that allows to specify number of characters at which the truncation happens, as this was needed anyway. Then also your use case will be handled

[bkamins]

I had to add truncate keyword argument for generality (as things are unfortunately problematic in corner cases). I have decided to never truncate: 1) row column name, 2) column name, 3) column eltype if shown.

[nalimilan]

We already abbreviate eltypes when they are too long, right?

[bkamins]

We already abbreviate eltypes when they are too long, right?

Yes, but now truncate can be less than we abbreviate (a corner case, but still).

[bkamins]

@nalimilan - this should be good to have a look at. Thank you!

[nalimilan]

Yes, but now truncate can be less than we abbreviate (a corner case, but still).

Can you give an example? I don't get it. :-)

[bkamins]

Can you give an example? I don't get it. :-)

I explicitly test this case here:

https://github.com/JuliaData/DataFrames.jl/pull/2403/files#diff-be8288df383517cc1dabe74772b7535aR723

[nalimilan]

Looks good with the small suggestion for the docstring.

[bkamins]

Thank you for fixing the docstring.

[bkamins]

Thank you!