continuing discussion from here. last comments:

@JanSchulz

I don't argue about that repr_*.help_files_with_topic should exist (yes, it should!) but where the best place is.

IMO the repr package can be more successful if it is the bare minimum API (aka repr_text.default via print) so that other packages which want to be "representable" can extend it by supplying repr_*.<object> for their own objects without getting a hit by many supplied "not-default-repr_*-functions" or having the namespace polluted by things which might surprise users (e.g. they want print for lists and only markdown for data.frames by loading pander).

repr_*.help_files_with_topic can exist in the IRkernel package without problem -> it's useable for help pages and if there is really a need for that in other packages, adding a repr-whatever packages with more implementations is also an option.

Thinking about it there needs to be a "API-ish" way to supply repr_*.data.frame so that pander/.. can use that to supply their own methods to generate such output when I do a library(pander). Is there a way to overwrite methods for a object type?

@takluyver

It's absolutely my intention that packages should generally specify their own repr_*.mytype methods for the types they define. I expect we'll need to provide a few such methods for core types like help, plots and dataframes, though. I'm ambivalent at the moment about whether they live in repr, IRdisplay, IRkernel or even a new package that we make for this purpose (base_reprs?).