Closed redzic closed 2 years ago
This issue seems to be related with the following codes:
https://github.com/console-rs/indicatif/blob/9cb25a71f466bbef39cf210c2a2ee238f7a02a62/src/style.rs#L241-L260 https://github.com/console-rs/indicatif/blob/9cb25a71f466bbef39cf210c2a2ee238f7a02a62/src/style.rs#L324-L349
If key
is "wide_bar" or "wide_msg", buf
will be set to \x00
, and the step of applying FirstStyle
to buf
is skipped. (Note that AltStlyle
will still take effect)
Here is a test case to show this issue:
// append this to `crate::style::tests`
// and run it by `cargo test style::tests::wide_element_style`
#[test]
fn wide_element_style() {
const CHARS: &str = "=>-";
const WIDTH: u16 = 8;
let pos = Arc::new(AtomicPosition::new());
// half finished
pos.set(2);
let state = ProgressState::new(Some(4), pos);
let mut buf = Vec::new();
let style = ProgressStyle::with_template("{wide_bar}")
.unwrap()
.progress_chars(CHARS);
style.format_state(&state, &mut buf, WIDTH);
assert_eq!(&buf[0], "====>---");
buf.clear();
let style = ProgressStyle::with_template("{wide_bar:.red.on_blue/green.on_cyan}")
.unwrap()
.progress_chars(CHARS);
style.format_state(&state, &mut buf, WIDTH);
assert_eq!(
&buf[0],
"\u{1b}[31m\u{1b}[44m====>\u{1b}[32m\u{1b}[46m---\u{1b}[0m\u{1b}[0m"
);
buf.clear();
let mut style = ProgressStyle::with_template("{wide_msg:^.red.on_blue}").unwrap();
style.message = "foobar".into();
style.format_state(&state, &mut buf, WIDTH);
assert_eq!(&buf[0], "\u{1b}[31m\u{1b}[44m foobar \u{1b}[0m");
}
Once the following part of code is commented, wide_bar
and wide_msg
are colored correctly.
But I'm not sure it's possible to simply remove this code without causing other bugs. Although all tests pass fine, including style::tests::align_truncation
introduced by the commit https://github.com/console-rs/indicatif/commit/5038ba8019bad296b5a0314770db5d05c050a7dd.
If you can submit a PR to fix this, that would be great!
It used to be that the progress bar template style supported coloring, but this behavior seems to have broken by commit 5038ba8019bad296b5a0314770db5d05c050a7dd according to git bisect.
Before that commit,
cargo run --release --example download
would print a progress bar where the hashes (#
) were colored in blue. Starting at that commit, they are printed as white. I don't think this is supposed to happen.