update: you can now get my silly li'l bitfield library from a crates.io near you: crates.io/crates/myceliu
Quote Tweet
update on this: i made a lil thingy
Show this thread
![bitfield! {
struct TestBitfield<u32> {
const HELLO = 4;
const _RESERVED_1 = 3;
const WORLD = 1;
const HAVE = 3;
const LOTS = 5;
const OF = 1;
const FUN = 6;
}
}
#[test]
fn test_bitfield_format() {
let test_bitfield = TestBitfield::new()
.set(TestBitfield::HELLO, 0b1001)
.set(TestBitfield::WORLD, 1)
.set(TestBitfield::HAVE, 3)
.set(TestBitfield::LOTS, 0b11010)
.set(TestBitfield::OF, 0)
.set(TestBitfield::FUN, 9);
println!("{}", test_bitfield);
}](https://pbs.twimg.com/media/FTubfw6UsAAl_1V?format=png&name=900x900)
read image description
ALT
read image description
ALT
5
18
189
Conversation
Damn. You just made me realize that as a crate author we can have ASCII art in the Debug impl, and that as a stdlib we could have a trait to standardize that behaviour.
2
2
42
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
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.
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
Finding the right level of abstraction for the separation might be tricky⦠eg. it would also be neat if at some level you could present stuff in an accessible, non-ascii-art way, and in the process also support non-ascii consumers.
2