it would be very cool if there was some kind of standardized trait for pretty-printing ascii graphics, *especially* if there was some way to slice up an ascii graphic with newlines so it can be, like, printed next to a different multi-line ascii graphicโฆbut thatโs suddenly a lot
Conversation
maybe worth starting with some kind of FmtAsciiArt trait in a crate that could make it into std eventually if itโs possible to come up with a good abstraction over it, idk
1
7
(it *does* get indented correctly if you put my Display impl in a fmt::DebugStruct field or similar with alt-mode enabledโฆbut the formatter puts a trailing comma after it, which looks weird with the ascii artโฆ)
2
6
I think that repurposing # for this is smart, also think that it'd be interesting if it could be term aware for colouring and the like. ๐ค
1
6
term-aware formatting in core::fmt would be amazingโฆ
1
6
std wouldnโt even need to implement the actual color codes and stuff, that could be left to third-party crates, if Formatter just had a way to say โiโm definitely writing to something that is a ttyโ
2
4
Maybe we should have a cli!() macro?
The thing that would be interesting is having an HTML style datatype for output and delay the formatting to right before it gets printed.
1
6
Not entirely the same, but OCaml has a `Format` module for pretty printing. I find it a bit janky tbh but it's cool that at least there is some standardisation: v2.ocaml.org/api/Format.html - you can add tags for additional formatting info: v2.ocaml.org/api/Format.htm.
1
2
The pretty crate supplies a similar โwhatever you wantโ style of annotation support as well: github.com/Marwes/pretty. - which allows you to add on colours if you want it at some level - integration with the fmt is difficult though (term width is also an issue).
2
2
This is what we're using on Flux, though it's not surprising since Markus is on the team ;)
1
2