Conversation

i mean, i just stuck it in the Display impl; i didn’t want to put it in Debug, because i feel like the expectation for Debug is that it’s single-line if alt-mode isn’t set, or respects indentation if alt-mode is set…which this doesn’t do super nicely
1
10
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
1
7
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
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
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