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

option to disable new print method color scheme #346

Closed
slonik-az opened this Issue Dec 27, 2017 · 15 comments

Comments

Projects
None yet
10 participants
@slonik-az

slonik-az commented Dec 27, 2017

Recently, tibble print method started printing some digits in pale grey making output hard to read. Also, a concept of three significant digits for integers makes no sense.

What option should I set to get back the old monochrome print method that does not highlight significant digits?

Thanks,
--Leo

tibble-ugly-grey

@krlmlr

This comment has been minimized.

Member

krlmlr commented Dec 27, 2017

Thanks for your feedback. The colored output attempts to highlight important parts while still printing everything. I wonder why it is important to you to read the exact values, maybe a separator every three digits would help?

If you prefer monochromatic output, you can set the option "crayon.enabled" to FALSE or turn off the colored console in RStudio. Both options will turn off colored output in other packages.

@slonik-az

This comment has been minimized.

slonik-az commented Dec 27, 2017

@krlmlr : Thanks for a quick reply and suggestions. In general, I like RStudio console colors but I have an issue with readability of pale-grey digits in new tibble printed output. I do not see rationale in highlighting first three digits of a long integer leaving the rest in pale grey. A zebra pattern with 3 digits long stripes would be better, i.e. 123456789.

In any case, it would be super-useful to have an option (like tibble.signif=FALSE) to disable highlighting of significant digits altogether. Right now I reverted back to tibble-1.3.4 but it is only a short-term solution.

Thanks, --Leo

@MaximilianBernkopf

This comment has been minimized.

MaximilianBernkopf commented Dec 28, 2017

First of all thanks for keeping up the awesome work.

I noticed something else regarding the new print method.
Under version 1.3.4 the columns were perfectly aligned:

tibble_1_3_4

But now it's getting a little hard to read:

tibble_1_4_1

Is there some intention behind that?

Thanks in advance.

@whanrott

This comment has been minimized.

whanrott commented Jan 2, 2018

Further to this issue... The code which recreates this issue for me is:

data_frame(numbers = c(1L,10L,100L,1000L), text = letters[1:4])
data_frame(numbers = c(1,10,100,1000), text = letters[1:4])
data_frame(text = letters[1:4], numbers = c(1L,10L,100L,1000L))
data_frame(text = letters[1:4], numbers = c(1,10,100,1000))

The result looks like this:
tibble_formatting_issue

My version details are:

platform       x86_64-pc-linux-gnu         
arch           x86_64                      
os             linux-gnu                   
system         x86_64, linux-gnu           
status                                     
major          3                           
minor          4.3                         
year           2017                        
month          11                          
day            30                          
svn rev        73796                       
language       R                           
version.string R version 3.4.3 (2017-11-30)
nickname       Kite-Eating Tree

I'm using dplyr version 0.7.4

@iacobus42

This comment has been minimized.

iacobus42 commented Jan 2, 2018

I too am running into issues with the new print method causing poor alignment issues. I have a few cases where the variable name is much shorter than the variable values (e.g., ID type variables) and this can cause alignment issues.

The following prints okay:

tibble(
  id = as.character(round(runif(10, 10^14, 10^15 - 1))),
  height = rnorm(10),
  weight = rnorm(10)
)

image

but when the ordering is changed, it does not print correctly:

tibble(
  height = rnorm(10),
  weight = rnorm(10),
  id = as.character(round(runif(10, 10^14, 10^15 - 1)))
)

image

It gets even more broken pretty quickly. Using a plausible data set:

tibble(
  id = as.character(round(runif(10, 10^14, 10^15 - 1))),
  height = rnorm(10),
  weight = rnorm(10),
  bmi = weight / height^2,
  female = rbinom(10, 1, 0.5),
  phone_number = as.character(round(runif(10, 10^10, 10^11 - 1))),
  runs = rbinom(10, 1, 0.5),
)

image

Indeed, this is visible even with something as simple as making mt_cars into a tibble and printing:

image

The UDJudgeRatings is even worse:

image

Will these be an option to completely disable this "pretty printing" of the data? It seems somewhat broken.

@billdenney

This comment has been minimized.

billdenney commented Jan 4, 2018

@krlmlr, In response to your comment above "I wonder why it is important to you to read the exact values, maybe a separator every three digits would help?"

I often need to read subject identifiers for clinical trials which can be a string of 3 to 9 digits (typically), and I then need to compare those numbers to numbers generated elsewhere. Precise readability is important for me, too.

Also, the readability of the light gray on white motif will impact people who have vision difficulty with low contrast images (http://www.allaboutvision.com/eye-exam/contrast-sensitivity.htm).

In most scenarios, I like having the added color help me quickly differentiate between various parts of the code and output, but having granular control of when it applies and when it doesn't would be beneficial.

@hadley

This comment has been minimized.

Member

hadley commented Jan 8, 2018

Mostly duplicate of r-lib/pillar#76, although there are a bunch of issues in here.

@hadley hadley closed this Jan 8, 2018

@eipi10

This comment has been minimized.

Contributor

eipi10 commented Jan 9, 2018

I see this issue is closed, but I also find that the new tibble print method with numbers partially greyed out makes output hard to read. Below is an example.

screen shot 2018-01-09 at 9 54 41 am

I have to admit I did a doubletake when I saw @krlmr's comment above "I wonder why it is important to you to read the exact values..." I'd turn that around and ask why is it important to make data output harder to read? The new print method just seems like a bizarre choice. For now I've rolled back to the previous version of tibble, but that's obviously not a long-term solution. I realize I can turn off the new printing style by changing the crayon.enabled option, but it would be better to have a reasonable default in the first place.

@krlmlr

This comment has been minimized.

Member

krlmlr commented Jan 10, 2018

There'll be an option to turn off highlighting altogether, and we should also work on more granular control.

The highlighting aims at making the important information easier to read while still including "everything". Of course if the number is in fact a subject identifier encoded as a number, as in Bill's case, all digits are important. I certainly missed that part.

@jennybc

This comment has been minimized.

Member

jennybc commented Jan 10, 2018

The "number that should not be formatted as a number" comes up a lot in spreadsheets too. I'm not sure if this has any practical implications but it's a connection worth noting. Product codes, social security numbers, etc. might look like numbers, but they're really more like strings over a numeric alphabet. In readxl, it's a constant effort when coercing to character to prevent the use of scientific notation or spurious decimal places.

@krlmlr

This comment has been minimized.

Member

krlmlr commented Jan 10, 2018

Maybe we just need an S3 class for sequences of digits that are not to be interpreted as numbers? Need to make sure that dplyr maintains this class in all verbs.

Detecting these numbers automatically (e.g. when importing spreadsheets) is a whole different class of problem, I assume.

@jennybc

This comment has been minimized.

Member

jennybc commented Jan 10, 2018

It's kind of interesting to ponder the extreme position that any such variable should really be stored as character. Then it becomes a coercion problem, not a printing problem.

I'm not sure we should do anything about this, at this point. I just think it's helpful to recognize the phenomenon.

@krlmlr

This comment has been minimized.

Member

krlmlr commented Jan 10, 2018

In theory, yes. In practice, always storing as character wastes storage and computation time, by an order of magnitude.

@AshesITR

This comment has been minimized.

AshesITR commented Feb 10, 2018

@krlmlr Pardon me for my ignorance, but don't you have options(pillar.subtle = FALSE) precisely for omiting the grey-out effect?

@krlmlr

This comment has been minimized.

Member

krlmlr commented Feb 10, 2018

Calling options(pillar.subtle_num = FALSE) should now give the desired effect for numbers only, options(pillar.subtle = FALSE) turns off greying for all elements (header, footer, row names).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment