Have a way to use Pluto default `show` for types which define a custom `show` method

[disberd]

Currently, if I create a type MyType and define a override Base.show(io::IO, x::MyType) or Base.show(io::IO, ::MIME"text/plain", x::MyType), then I lose the default show method in Pluto, and there is not method to get it back.

It would be good to be able to decide I want my type to have a custom show in the REPL but do not impact the Pluto default show method.

I remember somebody raised this issue question before in either zulip/discourse but can't find it anymore.

Discussed this today at the dev call and @fonsp also agrees that we should have this capability

[cstjean]

Having a way to "display this object as a Pluto object tree of ..." would also be very nice!

[MasonProtter]

Here's the Zulip thread with the request: https://julialang.zulipchat.com/#narrow/channel/243342-pluto.2Ejl/topic/show.20method

[MasonProtter]

Here's two potential ways to handle this:

1. Give users a function they can call, so that e.g. they can write

Base.show(io::IO, ::MIME"text/html", x::MyType) = PlutoRunner.pluto_show(io, x)

2. Define some trait they can overwrite that communicates to Pluto that it should use Pluto's tree-view instead of the regular show method

PlutoRunner.use_treeview(::MyType) = true

[cstjean]

Wouldn't it make sense to have a MIME"text/pluto"? Then users who don't want the HTML representation can write

Base.show(io::IO, mime::MIME"text/pluto", x::MyType) = @invoke show(io, mime, x::Any)

to get the default show(::IO, ::MIME"text/pluto", ::Any) fallback (which would itself follow the current logic of checking if a text/html is defined, and fallback to the tree viewer).

Furthermore,

• Some library could choose to define separate text/html and text/pluto methods
• No need to import PlutoRunner in a library to implement the above method

[fonsp]

We can add this the use_treeviewer trait to AbstractPlutoDingetjes! Feel free to make the PRs

[sethaxen]

In addition to a trait to indicate that tree viewer should be used, it would be helpful to be able to customize how the tree is rendered. e.g. I might have a container that ties metadata to data that's access with getproperty:

struct SomeContainer{I,M}
    items::I
    metadata::M
    SomeContainer(items; metadata=nothing) = SomeContainer(items, metadata)
end
Base.getproperty(c::SomeContainer, k::Symbol) = getproperty(getfield(c, :items), k)
Base.propertynames(c::SomeContainer) = propertynames(getfield(c, :items))
metadata(c::SomeContainer) = getfield(c, :metadata)

I'd like the treeview to be something like that for items but with the type name being SomeContainer{...}. For this use-case, having a method where I get to reformat the object to another valid tree would be useful, but maybe there are more complicated use-cases where that wouldn't be enough?

[fonsp]

Nice! I would be happy to add this to AbstractPlutoDingetjes if someone can think of a good spec.

We should start by collecting a list of use cases.