setting message doesn't trigger re-draw

[mcginty]

have to call tick() afterwards to get it to show the message

[nabijaczleweli]

That should be the default behaviour

[mcginty]

Why? It seems like if you set the message on a progress bar, that should be the message that's displayed?

[nabijaczleweli]

Because double-redrawing every tick is really bad?
Code example of correct usage of ProgressBar::message()

// or, y'know, iterate over current dir, it's too early to do that so I hardcoded it
static FILES: &'static [&'static str] = &[".gitignore", ".travis.yml", "Cargo.lock", "Cargo.toml", "LICENSE", "README.md", "appveyor.yml", "assets/icon.png", "gh_rsa.enc", "not-stakkr.sublime-project", "not-stakkr.sublime-workspace", "rustfmt.toml", "src/lib.rs", "src/main.rs", "src/ops/init.rs", "src/ops/mod.rs", "src/ops/token.rs", "src/options.rs", "src/outcome.rs", "src/util.rs", "tests/mod.rs", "tests/util/mod.rs", "tests/util/prompt_exact_len.rs"];

let mut pb = ProgressBar::new(FILES.len());
for f in FILES {
    pb.message(f);
    pb.inc();
    thread::sleep_ms(5);
}

[mcginty]

Lol, thumbs down. Ouch.

Yeah, I get what you're saying, but the underlying issue around that seems like an architectural challenge of either having a transactional API or having an animation thread.

In my project, for example, I've wrapped pb in a thread that animates at a specified framerate, and it queues up actions to be executed in the next display frame. Perhaps this is something pb should just do to solve this problem.

[winstonewert]

I think we should leave as is.

None of the show/tick/message options trigger redraws upon changes.

I think there is merit in the approach suggested where a seperate thread updates the UX at a particular frame rate. However, that is a rather different approach to what pb is doing and would require a complete rearchitecture of the system. So, perhaps there is a place for a crate that does that, but pb isn't it.