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

Commands should respect USE_COLORIZE config #362

Merged
merged 3 commits into from
Jun 20, 2022

Conversation

st0012
Copy link
Member

@st0012 st0012 commented May 9, 2022

Currently, colored commands ls and show_source doesn't respect the USE_COLORIZE config:

截圖 2022-05-09 12 04 28

This PR addresses the issue and here's the result:

截圖 2022-05-09 12 07 48

截圖 2022-05-09 12 11 44

BTW as suggested in #351 (comment), I think irb should adopt the NO_COLOR env var for easier no-color config.

@st0012
Copy link
Member Author

st0012 commented Jun 19, 2022

@peterzhu2118 Would you mind giving it a look? Thx

Copy link
Member

@peterzhu2118 peterzhu2118 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thank you!

@peterzhu2118 peterzhu2118 merged commit 534688d into ruby:master Jun 20, 2022
@st0012 st0012 deleted the respect-colorize branch June 20, 2022 13:28
st0012 added a commit to st0012/irb that referenced this pull request Jun 26, 2022
There are 2 requirements for coloring output:

1. It's supported on the platform
2. The user wants it: `IRB.conf[:USE_COLORIZE] == true`

Right now we check 1 and 2 separately whenever we colorize things.
But it's error-prone because while 1 is the default of `colorable`
parameter, 2 always need to manually checked. When 2 is overlooked, it
causes issues like ruby#362

And there's 0 case where we may want to colorize even when the user
disables it. So I think we should merge 2 into `Color.colorable?` so it
can be automatically picked up.
peterzhu2118 pushed a commit that referenced this pull request Jun 28, 2022
* Use colorable: argument as the only coloring control

* Centalize color controling logic at Color.colorable?

There are 2 requirements for coloring output:

1. It's supported on the platform
2. The user wants it: `IRB.conf[:USE_COLORIZE] == true`

Right now we check 1 and 2 separately whenever we colorize things.
But it's error-prone because while 1 is the default of `colorable`
parameter, 2 always need to manually checked. When 2 is overlooked, it
causes issues like #362

And there's 0 case where we may want to colorize even when the user
disables it. So I think we should merge 2 into `Color.colorable?` so it
can be automatically picked up.

* Add tests for all inspect modes

* Simplify inspectors' coloring logic

* Replace use_colorize? with Color.colorable?

* Remove Context#use_colorize cause it's redundant
matzbot pushed a commit to ruby/ruby that referenced this pull request Jun 28, 2022
* Use colorable: argument as the only coloring control

* Centalize color controling logic at Color.colorable?

There are 2 requirements for coloring output:

1. It's supported on the platform
2. The user wants it: `IRB.conf[:USE_COLORIZE] == true`

Right now we check 1 and 2 separately whenever we colorize things.
But it's error-prone because while 1 is the default of `colorable`
parameter, 2 always need to manually checked. When 2 is overlooked, it
causes issues like ruby/irb#362

And there's 0 case where we may want to colorize even when the user
disables it. So I think we should merge 2 into `Color.colorable?` so it
can be automatically picked up.

* Add tests for all inspect modes

* Simplify inspectors' coloring logic

* Replace use_colorize? with Color.colorable?

* Remove Context#use_colorize cause it's redundant

ruby/irb@1c53023ac4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants