Skip to content
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

add .cargo/config settings to control output colors #2367

Closed
wants to merge 1 commit into from

Conversation

oconnor663
Copy link

#2290

This is my first time submitting a Rust PR, so please give me lots of corrections. An example ~/.cargo/config file setting these options would be:

[color]
status_color = "green"
status_bold = false

I picked the config names more or less at random, so I'm happy to change those. I went with the simple approach of adding an extra condition to our current use of Attr::Bold, but we could also consider letting the color strings represent boldness/brightness on their own.

Naive question for the folks who know more about Rust and this code: why is it that Config contains a bunch of RefCells rather than owning its data directly?

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@alexcrichton alexcrichton assigned alexcrichton and unassigned huonw Feb 8, 2016
@alexcrichton
Copy link
Member

Thanks for the PR @oconnor663! The implementation here looks good to me, it's just largely a question of design now. Some suggestions I might have are:

  • We may want to support color.enabled as a key to globally enable/disable colors in Cargo
  • Config keys currently use hyphens rather than underscores, so these may want to be called status-color and status-bold
  • The [color] table may even want to be renamed to [term] to allow for configuring all terminal-like output Cargo does. For example one day we may have a curses interface?
  • I'm a little worried with regard to future extensibility of this kind of configuration.

Today the terms "status color" and "status bold" make sense, but it may not always have a meaning in future iterations of Cargo's UI. I'm not sure that there's really a great way to resolve this, and there's two ways to go here I think. On one hand we can make the configuration here generic (e.g. "bold = true", "color = green"), and then try to interpret that wherever possible. On the other hand we could make it super specific (e.g. as-is with the term "status") and then simply not interpret the keys in the future if we change the UI.

I think I would personally lean a bit more towards the more-generic aspects so we can hopefully take existing configurations into account for future UI changes, but I'm curious as to your thoughts as well!


As to the PR itself, could you add a few more pieces as well?

  • Can you update src/doc/config.md with the new configuration keys as well as an explanation of what they do?
  • Can some tests be added, primarily for invalid configuration?

@alexcrichton alexcrichton added the relnotes Release-note worthy label Feb 8, 2016
@alexcrichton
Copy link
Member

I got a chance to talk with @wycats about this today and some thoughts were:

  • Looks like there's precedent for this (it's in git at least), so that's good
  • We agree on renaming these options perhaps with hyphens and [term]
  • It's tough to say whether this is the best solution. If you feel the need to configure Cargo's colors, you probably also want to configure everything else's colors. It's unfortunate that there's more than one point of configuration here, but there may not be much we can do about that.
  • This seems well motivated in any case, and we can perhaps sorry about more global configuration (e.g. reading some "canonical configuration") later on.

@oconnor663
Copy link
Author

That all sounds good, thanks for following up. I'll probably get back to this "sometime in the next few weeks", so if anyone is itching to take it over in the meantime, that's totally cool too.

@bors
Copy link
Contributor

bors commented Mar 17, 2016

☔ The latest upstream changes (presumably #2480) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Copy link
Member

Closing due to inactivity, but feel free to resubmit with a rebase!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Release-note worthy
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants