feat: tbl_format_setup() gains a setup argument that supports printing the header before the data for the body is available, e.g., for remote backends such as databases

[krlmlr]

This supports printing the header before the body or footer is ready. Adding the setup argument to tbl_format_setup() was the easiest way I found to achieve this. The two commits are self-contained.

[krlmlr]

This is likely to affect dbplyr by no longer showing the number of rows in the header if it's less than 21. I'd trade that for showing the header first. And I wonder if we should temporarily show the structure of the data too, and erase it (with \r?) when the body is ready.

[DavisVaughan]

This feels quite "spooky" to me

In particular I found relying on "did setup get evaluated or not" a bit hard to understand and document.

Is it possible that new_tbl_format_setup() could gain a boolean argument that identifies whether or not this is a "partial" setup?

Like:

• If we see is.null(setup) then we do partial setup and return with partial = TRUE.
• That causes tbl_format_setup() to get called again, but with !is.null(setup) this time (i.e. it gets the results of the original partial setup), so we do the full setup and return with partial = FALSE

[DavisVaughan]

I'd add a note in here about the fact that "If setup is evaluated by the tbl_format_setup() method, then that's our signal to recall tbl_format_setup() a second time"

[DavisVaughan]

What does transform() do?

[krlmlr]

transform is writeLines when printing and identity when formatting. This is how we achieve incremental printing.

Adding a comment to that effect to the code.

[DavisVaughan]

Probably worth a news bullet

[krlmlr]

Thanks. I see how it's spooky, I couldn't think of a better way.

We want to be compatible with existing implementations of tbl_format_setup() who might not know or care about the new flow. We effectively implement a "pre-setup" (for just the header) and a "setup for real" (for the body and footer), the fallback being just one setup call. Should we do a new generic instead, or perhaps two new generics? What would they look like, what would the migration path look like?

[krlmlr]

Going with this implementation for now, we can revisit as needed.