Currently the Turn@text getter is used to convert a turn into text by calling contents_text() on the elements in the turn's @contents. The text representation, however, loses critical information, such as hiding the images attached to the contents.
I think it's reasonable for this to happen with Turn@text, but for more complicated uses it'd be helpful to have a way to also get an html or markdown representation of the Turns.
Rather than increasing the number of properties on Turn, I'd like to propose that contents_text() becomes an exported function and is joined by contents_markdown() and contents_html() (possibly also supported by a extending an underlying, possibly exported, abstraction of contents_transform()).
Ideally, these functions could be defined for the content classes ContentText, ContentInlineImage, etc. as well as for Turn, such that a user could call lapply(chat$get_turns(), contents_html) or equally contents_html(chat$get_turns()[[1]]).
Currently the
Turn@textgetter is used to convert a turn into text by callingcontents_text()on the elements in the turn's@contents. The text representation, however, loses critical information, such as hiding the images attached to the contents.I think it's reasonable for this to happen with
Turn@text, but for more complicated uses it'd be helpful to have a way to also get an html or markdown representation of the Turns.Rather than increasing the number of properties on
Turn, I'd like to propose thatcontents_text()becomes an exported function and is joined bycontents_markdown()andcontents_html()(possibly also supported by a extending an underlying, possibly exported, abstraction ofcontents_transform()).Ideally, these functions could be defined for the content classes
ContentText,ContentInlineImage, etc. as well as forTurn, such that a user could calllapply(chat$get_turns(), contents_html)or equallycontents_html(chat$get_turns()[[1]]).