I understand your points (and it would be incredibly easier to support PrettyTables.jl without those features 
). However, PrettyTables.jl is being used to a very wide audience. I have received tons of feature requests, which includes summary rows and columns.
My main use case (printing satellite telemetry data) is quite opposite. A summary column would be very important because it can be used to indicate possible problems in a frame.
I am kinda similar to the concerns of @pdeffebach – would we be able to suppress the output of these summary columns and values in our tables?
I agree with the concerns about summary statistics — IMO these should not be displayed by default. I would look for a tool like PrettyTables.jl to display tables of my own creation and not try to make guesswork at what my table “really” should have been.
I will follow the same approach we have today. The user will be able to suppress all the fields shown in that schematic.
In fact, if no other option is passed, PrettyTables will just print the column labels (which it can guess if nothing is passed) and the data.
All other fields require additional input as we have today.
I feel like @pdeffebach and probably even more. Would it be possible to have a base/core module that prints text only? I mean a base module that has no dependencies and upon which all other options/backends build up as optional extensions?
Not without an additional maintainability burden. But the question is why? PrettyTables takes less than 0.05s to print the first table…
Sure, but it feels like calculating summary statistics is a step too far. It’s pretty easy to push a few rows to the end of a table yourself. I don’t see why this needs to be automated by PrettyTables.
Actually is not a summary statistics, it is a function that you can do whatever you want. Let’s say your software provides a huge number of data in a table, using a format that you cannot modify, but it is compatible with Tables.jl. You can use this feature to provide a summary over the entire row / column.
The API is just f(data, i) where i is the row or column.
Furthermore, since those are different fields, we can have very nice API to decorate those rows and columns to make the presentation nicer for publication.
In my case, I will use those fields to check for occurrences in satellite telemetry.
However… I am really thinking of removing the summary columns and let only the summary rows. It seems that the use cases are indeed small and it will add a significant amount of work in each backend (mainly in text).
I’m glad PrettyTables wouldn’t be doing too much work on it’s own.
I think this discussion really highlights the need for better table-viewing capabilities. Thanks to you we have TerminalPager.jl. I maintain FloatingTableView.jl (but it might be better to say it is unmaintained, since Blink.jl has fallen by the wayside). Neither of these options are very snappy for large tables.
Well, it’s not for speed but for not wishing to add dependencies that I don’t need.
PrettyTables.jl has only six dependencies (excluding stdlibs), and one of them is PrecompileTools.jl.
There is also GitHub - queryverse/ElectronDisplay.jl: An Electron.jl based figure and table display., but I haven’t tried that in years 
Because really, I’m just using the built-in table viewer in the VS Code extension.
If someone has the funding and time, they should implement a way to use QT’s lazy table view to look at a large data set, which is what Stata uses to have such a good data viewer.
This is one feature I might be able to solve with TerminalPager.jl using the new version of PrettyTables.jl. If we fix the size of the columns, we can render the chunks of tabular data so that the user can scroll without waiting for the entire table to be rendered.
My idea is to create a package called TerminalTables.jl or something that uses the algorithms in TerminalPager.jl to deploy a system for rendering tables using PrettyTables to the terminal in a “lazy” manner.
The problem is time 
This will be no easy task.
Hi!
The markdown back end is finished! Since now it is easier to test PrettyTables.jl v3 in REPL, it might be a good time for people who use PrettyTables.jl to test the new API (branch v3). We can still make some minor adjustments 
julia> pretty_table(
A;
back_end = :markdown,
title = "PrettyTables.jl v3 Test",
subtitle = "Random Data",
row_labels = 1:10,
stubhead_label = "Rows",
summary_rows = [
(data, i) -> sum(@views data[:, i]) / size(data, 1),
(data, i) -> maximum(@views data[:, i]),
(data, i) -> minimum(@views data[:, i])
],
summary_row_labels = ["Mean", "Max.", "Min."],
footnotes = [
(:column_label, 1, 1) => "This is a footnote.",
(:data, 2, 2) => "This is another footnote.",
],
source_notes = "Source: Random data for testing PrettyTables.jl.",
maximum_number_of_rows = 7,
maximum_number_of_columns = 7,
vertical_crop_mode = :middle
)
# PrettyTables.jl v3 Test
## Random Data
| **Rows** | **Col. 1[^1]** | **Col. 2** | **Col. 3** | **Col. 4** | **Col. 5** | **Col. 6** | **Col. 7** | ⋯ |
|---------:|---------------:|------------:|-----------:|-----------:|-----------:|-----------:|-----------:|---|
| **1** | 0.0860125 | 0.391815 | 0.985232 | 0.376865 | 0.718722 | 0.944482 | 0.834032 | ⋯ |
| **2** | 0.356033 | 0.60825[^2] | 0.72248 | 0.849522 | 0.295322 | 0.862703 | 0.455513 | ⋯ |
| **3** | 0.0729634 | 0.695804 | 0.71853 | 0.527695 | 0.521153 | 0.748883 | 0.0185001 | ⋯ |
| **4** | 0.489404 | 0.311403 | 0.846375 | 0.313131 | 0.214182 | 0.0710855 | 0.117701 | ⋯ |
| ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋱ |
| **8** | 0.51517 | 0.722422 | 0.632347 | 0.914253 | 0.996468 | 0.95932 | 0.545074 | ⋯ |
| **9** | 0.280298 | 0.0103098 | 0.523993 | 0.734877 | 0.17862 | 0.934306 | 0.0609594 | ⋯ |
| **10** | 0.0153091 | 0.376121 | 0.0858657 | 0.605649 | 0.167625 | 0.529653 | 0.379238 | ⋯ |
| -------- | -------------- | ----------- | ---------- | ---------- | ---------- | ---------- | ---------- | ⋯ |
| **Mean** | 0.248587 | 0.460679 | 0.656974 | 0.510822 | 0.518404 | 0.611873 | 0.327743 | ⋯ |
| **Max.** | 0.601084 | 0.722422 | 0.985232 | 0.914253 | 0.996468 | 0.95932 | 0.834032 | ⋯ |
| **Min.** | 0.00273123 | 0.0103098 | 0.0858657 | 0.057668 | 0.167625 | 0.0246216 | 0.0152495 | ⋯ |
[^1] This is a footnote.
[^2] This is another footnote.
Source: Random data for testing PrettyTables.jl.
| Rows | Col. 1[^1] | Col. 2 | Col. 3 | Col. 4 | Col. 5 | Col. 6 | Col. 7 | ⋯ |
|---|---|---|---|---|---|---|---|---|
| 1 | 0.0860125 | 0.391815 | 0.985232 | 0.376865 | 0.718722 | 0.944482 | 0.834032 | ⋯ |
| 2 | 0.356033 | 0.60825[^2] | 0.72248 | 0.849522 | 0.295322 | 0.862703 | 0.455513 | ⋯ |
| 3 | 0.0729634 | 0.695804 | 0.71853 | 0.527695 | 0.521153 | 0.748883 | 0.0185001 | ⋯ |
| 4 | 0.489404 | 0.311403 | 0.846375 | 0.313131 | 0.214182 | 0.0710855 | 0.117701 | ⋯ |
| ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋱ |
| 8 | 0.51517 | 0.722422 | 0.632347 | 0.914253 | 0.996468 | 0.95932 | 0.545074 | ⋯ |
| 9 | 0.280298 | 0.0103098 | 0.523993 | 0.734877 | 0.17862 | 0.934306 | 0.0609594 | ⋯ |
| 10 | 0.0153091 | 0.376121 | 0.0858657 | 0.605649 | 0.167625 | 0.529653 | 0.379238 | ⋯ |
| -------- | -------------- | ----------- | ---------- | ---------- | ---------- | ---------- | ---------- | ⋯ |
| Mean | 0.248587 | 0.460679 | 0.656974 | 0.510822 | 0.518404 | 0.611873 | 0.327743 | ⋯ |
| Max. | 0.601084 | 0.722422 | 0.985232 | 0.914253 | 0.996468 | 0.95932 | 0.834032 | ⋯ |
| Min. | 0.00273123 | 0.0103098 | 0.0858657 | 0.057668 | 0.167625 | 0.0246216 | 0.0152495 | ⋯ |
[^1] This is a footnote.
[^2] This is another footnote.
Source: Random data for testing PrettyTables.jl.
Frivolous comment but I find the "Col. 4" abbreviation a little ugly. I’d prefer Column 4 or just 4.
Me too! However, most of the time Column X occupies too much space in the terminal For example, if you have a matrix with 15 columns, that requires 45 additional spaces.
Any way, you can change it by passing column_labels.
I think Column 4 is only 2 more characters than Col. 4 so 15 columns would only take 30 more.
12345678
Col. 4
Column 4
And what about just putting the number 4 without Col. ?
Yes! You are right! But 30 still is too much for terminals