Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New vector classes designed for better printing? #144

Closed
hadley opened this issue Aug 10, 2016 · 10 comments · Fixed by #294
Closed

New vector classes designed for better printing? #144

hadley opened this issue Aug 10, 2016 · 10 comments · Fixed by #294

Comments

@hadley
Copy link
Member

hadley commented Aug 10, 2016

I wonder if some of the complexities of tibble printing could be pushed off to individual vector formatters. Truncating strings (at least on a local level) could be useful in other places, and could be pushed down to the vector level. Another useful display type would be for logicals, printing TRUEs as "*" and leaving FALSEs blank. Maybe the same principle applies to better formatting for doubles too?

I don't think this changes what tools tibble should provide, but it may influence how we think about providing them.

@krlmlr krlmlr added the ready label Aug 10, 2016
@krlmlr
Copy link
Member

krlmlr commented Aug 10, 2016

Sounds like a good idea. I suspect this also helps cleaning up the formatting code. I can create a draft the next time I'll work on tibble.

@huftis
Copy link

huftis commented Aug 14, 2016

@hadley About printing TRUE as * and FALSE as blank, how would you differentiate between FALSE and NA (or would NA still be displayed as NA, or as N)?

How about T and F instead? Though this might encourage people to begin using T and F in their code, which is bad practice. So perhaps + and ?

@hadley
Copy link
Member Author

hadley commented Aug 14, 2016

NA would still be printed as is

@jankatins
Copy link

Regarding the overall approach: if one takes the requirements and algorithm of a overall tibble printing function from #104 (comment), then delegating the printing down to individual vectors requires a two pass approach: one to get the minimum required length of each vector (will probably do something like min(<internal min value fot that vector type>, nchars(name)) and one to do the print in the specific length (bigger or equal than the required length).

So either this becomes two S3 functions (one to get the min length of a vector, one to get the string representation of a vector) or the tibble print still needs to know the min length of each vector type :-/

@krlmlr
Copy link
Member

krlmlr commented Aug 22, 2016

I don't mind two new S3 methods col_width_preference() and format_col(), the former would return a named list that contains minimum and maximum width. In addition, there should be a compound class that also includes the column name and type in the calculations and formatting.

@hadley
Copy link
Member Author

hadley commented Aug 22, 2016

I'd prefer col_width() which could return a named list: min, max, preferred. (That might be a bit too general, but it's what other layout systems do)

@krlmlr krlmlr modified the milestone: 1.3 Aug 26, 2016
@krlmlr
Copy link
Member

krlmlr commented Apr 17, 2017

Closing in favor of #235.

@hadley
Copy link
Member Author

hadley commented May 15, 2017

I'd recommend closing in favour of https://github.com/hadley/colformat

@krlmlr
Copy link
Member

krlmlr commented May 15, 2017

We can implement the logic in colformat, but let's leave this open as a reminder and for tibble + colformat integration.

@github-actions
Copy link
Contributor

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.

@github-actions github-actions bot locked and limited conversation to collaborators Dec 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants