Ability to suppress "Finished dev target" and "Running <path>" lines without hiding progress indicators

[5225225]

Describe the problem you are trying to solve

I've started using cargo run --quiet (aliased to cr) to avoid the

Finished dev [unoptimized + debuginfo] target(s) in 0.06s
 Running `<path>`

lines that show up on every cargo run, since I often work with programs that only emit a few lines of output, and want to keep my scrollback as clean as possible, the lines are pure noise to me.

However, this also gets rid of progress indicators for downloads and builds, which make it hard to tell how how long it will be until the program starts, or even if the program has started yet, if cargo has things to do before running.

Describe the solution you'd like

A flag to just hide the Finished/Running lines that show up.

Alternatively, only show them if cargo is running in --verbose or had any actions to perform?

Or don't show them if they would have been the only output from cargo, show them otherwise? Not sure of the best method here.

[jschwe]

I am interested in adding this (at least for the Finished line). Would there be capacity to review such a PR?

I would

• add an unstable flag to hide the "Finished" line
• Potentially this flag would only hide the "Finished" line if all Jobs were "Fresh" (in addition to the flag being present). The freshness check would probably make it more difficult to support suppressing the Running line, since the freshness information would need to be propogated.

[mcandre]

quiet should mean quiet

[bonsairobo]

I'm in favor of changing the default output to have a better UX, while still supporting the spammy output with --verbose.

Strawman proposal:

1. No arguments: Only print warnings, errors, and a progress bar. I have to assume almost everyone is ignoring the spammy "Compiling foo" lines anyway.
2. --verbose: Include the spam.
3. --quiet: I think the current behavior is good. Some might argue that even warnings are not quiet enough?? I'm less aware of the motivations behind using --quiet.

[epage]

To re-phrase my proposal in #8889, the idea I have is that output is split into "sticky" and "non-sticky".

• Sticky output, like warnings an errors, persists
• Non-sticky output (most status messages) will be cleared when their parent operation is done

I did say "most status messages", not "all". My ideal "first step" would be for each command to have a "summary" status message that is sticky. Due to how we compose things, this might initially be a "summary per step" (cargo test showing compile and test summaries) rather than a single "command summary" (test summary). Cargo scripts would have no run summary (maybe a compile summary if something was built). I think at that point we'd be in a better situation to evaluate removing the summary completely though I personally lean against it this time.