Better support for Pluto.jl and IJulia.jl

[karlwessel]

I would like to use PrettyTables to format the display of Tables-like data in Pluto and IJulia notebooks.

The Problem with Pluto-notebooks and PrettyTables is that Pluto only displays the resulting object of a cell, not anything that was printed with print. This is on purpose and makes sense to me. And it works nicely for most custom types like Plots or DataFrames, since they can decide for each frontend (REPL or Pluto and IJulia) how they want to display them self.

It works not as nicely with PrettyTables since it either prints to STDOUT or returns a string. The former is not shown in Pluto and the latter only shows the content of the string, it is not interpreted.

These Problems would be solved nicely if PrettyTables.jl could extend its API by something like the Plots-API where something like a prettytable-Method would return a custom type that stores the data and the formatting.
Support for the correct display on the different frontends could then be added by extending the show-Method for the according MIME types.

[ronisbr]

Hi @karlwessel !

I think this approach is not good for PrettyTables. Notice that DataFrames, for example, creates new types. Thus, you can overload show to print them. PrettyTables, on the other hand, only tries to print data that is stored in a tabular fashion. Hence, a structure to define how to "print" so that you can create a show overload will have a very small gain. In fact, it will just be something with the keyword arguments that you pass to pretty_table.

However, what we can do here is to add another backend to support Pluto.jl, for example. Can you please provide some screenshots of what problems you are having?

[karlwessel]

In short: I should have just thought a bit more and read the manual :)

In long:
With a bit of distance in time I think my original Problem were two or three issues I mixed up because I didn't put enough thought to it, so let me try to disentangle them :-)

The original, practical Problem that I had to solve was that DataFrames in Pluto are rendered like this per default:

Which is nice for an interactive notebook but for "publishing" it as a pdf I wanted to get rid of things like the Datatype and the size of the Dataframe in the output.

PrettyTables seemed like the perfect solution for that, especially since it supports html which Pluto should be able to display. The html-version can be nicely rendered with Pluto.jl:

However, for a pdf, I would prefer the latex style and I imagined that the latex backend would be much better suited. However, I just couldn't find a way to get Pluto to display the Latex-String returned by pretty_table.

In hindsight that last thought was stupid: just because Pluto is able to render markdown which supports equations written in latex style doesn't mean that Pluto has to be able to render latex tables.

The direct solution to this Problem would be, me just reading the documentation of PrettyTables to learn how to format the html-backend output to look like latex tables:

However, I thought that what I really was missing is something like Plots.jl for Tables. I want to define the style of a table without having to care about the backend used to display that table. The backend could ideally be chosen by the frontend. The REPL would chose a text backend and IJulia and Pluto would chose HTML backend. The user just has to define how it should look like.

Again, with hindsight, this is probably much more complicated than I thought. Just because PrettyTables supports different backends and different styles doesn't mean it would be easy to support different backends to display the same style. And without that there is no point in the frontend automatically chosing the backend.

[ronisbr]

However, I thought that what I really was missing is something like Plots.jl for Tables. I want to define the style of a table without having to care about the backend used to display that table. The backend could ideally be chosen by the frontend. The REPL would chose a text backend and IJulia and Pluto would chose HTML backend. The user just has to define how it should look like.

Ah! Now I understand. This was my original goal. However, the way we format text output is much different than the way we format LaTeX for example. Thus, creating a universal structure would be very, very difficult and would also limit the possibilities. That's why I separated the format to be specific to each backend.

Maybe, in the future, we can create a package that works on top of PrettyTables to unify those things. I think we need to let PrettyTables.jl be as customizable as possible for now.

[karlwessel]

Yes, that it is much more complicated than I originally thought was also what I figured in the end. :)