Skip to content

feat: -q/--quiet for quietening progress output #12076

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

wooster0
Copy link
Contributor

@wooster0 wooster0 commented Jul 11, 2022

2022-07-10.23-23-25.mp4

Here's why I think Zig might be attractive to language devs as a language to compile to:

  • Zig compiles quickly (and will only get quicker in the future).
  • Zig has multiple codegen backends.
  • Zig has structs with unspecified field order for performance and other optimizations Zig facilitates that are not available in C.

And with this option Zig will be even more attractive as a language to compile to because now people can abstract zig being invoked under the hood to do the codegen for their language.

Of course, there are more reasons you might want to silence zig's compile output. In fact, maybe as part of your workflow zig runs somewhere else where nobody sees it so by using -q you can silence the output that nobody sees anyway and possibly gain a few negligible milliseconds or so of improved compilation speed.

@wooster0 wooster0 force-pushed the be_quiet branch 2 times, most recently from f0de179 to 66a9a52 Compare July 11, 2022 16:11
@andrewrk
Copy link
Member

Can you give an example where someone would want to use -q instead of --color off?

@wooster0
Copy link
Contributor Author

wooster0 commented Jul 12, 2022

  1. I think -q is kind of conventional. One could expect a compiler to have this option, similarly to expecting --color to be an option.
  2. I don't think --color off should turn off progress output. It's unexpected. The documentation is misleading too. The things should be separate.

So all in all I think some change is required here. TERM=dumb turning off both color and progress output makes sense however.

@wooster0
Copy link
Contributor Author

wooster0 commented Oct 16, 2022

I fixed this PR and addressed my comment above; here's a conclusion:

  • --color off no longer turns off progress output but turns off color.
  • TERM=dumb turns off progress output and color.
  • NO_COLOR= leaves progress output on but turns off color (same as --color off; can probably be removed).
  • --quiet turns off progress output and leaves on color.
  • ZIG_DEBUG_COLOR= leaves on progress output and leaves on color (I don't know why we need this?)

Did I miss anything?

I think this is the expected behavior.

This also kind of goes in hand with #12989 after which this will look clearer.

By the way, I think we could also remove --color auto but apart from that this PR is still mergeable as-is.

@wooster0
Copy link
Contributor Author

I can rebase and resolve the conflicts if my conclusion above is agreed to. Otherwise, feel free to close.

@wooster0
Copy link
Contributor Author

wooster0 commented Jan 7, 2023

So I'm in a situation right now where I would really like to turn off progress output but leave on color. I cannot find any way to do this. This PR seems to fix this.

Looking back at it, I still think we should remove NO_COLOR, ZIG_DEBUG_COLOR, and --color auto. Why make it so hard to choose? --color off to turn off only color and --quiet to turn off progress output makes perfect sense to me. And finally TERM=dumb would still disable both.

@Vexu
Copy link
Member

Vexu commented Jan 17, 2023

So I'm in a situation right now where I would really like to turn off progress output but leave on color.

The docgen could also use this though parsing the escape sequences produced by std.Progress isn't too hard either.

@andrewrk
Copy link
Member

Thanks for this patch. This is a bit tricky of a problem to sort out so I want to personally examine it carefully. I'm tackling this as part of #14647.

@andrewrk andrewrk closed this Feb 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants