There seems to be bug related to printing data.table when max.print option has been used. Tested on 1.9.6 and 1.9.7.
update: old example removed as it was far from minimal.
this is resolved by using proper option options(datatable.print.nrows=100).
Re-opening, because the number of omitted rows in the footer seems to be incorrect, that should be fixed.
library(data.table)
DT = as.data.table(iris)
options(max.print=5L)
print(iris)
# Sepal.Length Sepal.Width Petal.Length Petal.Width Species
#1 5.1 3.5 1.4 0.2 setosa
# [ reached 'max' / getOption("max.print") -- omitted 149 rows ]
print(DT)
# Sepal.Length Sepal.Width Petal.Length Petal.Width Species
# 1: 5.1 3.5 1.4 0.2 setosa
# [ reached getOption("max.print") -- omitted 10 rows ]
it is happening because the object to print is already reduced to head and tail, and max.print limit is being called on that reduced object.
In above example, there are 150 total rows, 1 row displayed. My guess is as follows... print.data.table reduce the number 150 to 12 rows (6 rows in head, 6 rows in tail), there is also 1 extra special row that separates head from tail (called ---), that we need to subract from 12(?), then we are ending up with 11 rows, and 1 row is being printed, thus "omitted 10 rows".
comment updated, fyi @shrektan
Another important note is that using
options(datatable.print.class = TRUE) # default in .Rprofile via .dev/cc.R
will affect max.print option as well.
I think we also have the register of column names at the bottom to consider, as controlled by col.names argument
The reason of this happening is that we convert the "reduced table" to a string matrix then call print() on that reduced table. Since print() is controlled by R and we can do nothing on that.
A possible solution would be we don't use print() internally any longer. Instead, we print the table by using cat(), where we could handle the option(max.print) by ourselves.