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

Increase the output color of search results #10116

Closed
wants to merge 9 commits into from

Conversation

heisen-li
Copy link
Contributor

close #9918

@rust-highfive
Copy link

r? @Eh2406

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 24, 2021
@heisen-li
Copy link
Contributor Author

Why the test task has not passed? I'm still looking for the reason. If anyone knows, feel free to let me know.

@ehuss
Copy link
Contributor

ehuss commented Nov 24, 2021

Why the test task has not passed?

status() goes to stderr, it can't be used for displaying the search results to stdout.

@heisen-li
Copy link
Contributor Author

Why the test task has not passed?

status() goes to stderr, it can't be used for displaying the search results to stdout.

thanks. I didn't notice, I was too careless. The failed test now seems to have nothing to do with me or something.

@ehuss
Copy link
Contributor

ehuss commented Nov 25, 2021

Sorry if I wasn't clear. The tests can't change to check stderr, the code will need to be changed to use stdout. I don't think the status function can be used here.

I opened #10120 to track the spurious CI error.

@heisen-li
Copy link
Contributor Author

Thanks, you are right.
The two are indeed different, and the test code cannot be changed rashly.

Currently there is an output method for stderr, but there is no corresponding method for stdout. As a supplement, I added a corresponding output method for stdout.

@ehuss
Copy link
Contributor

ehuss commented Dec 14, 2021

We talked about this a bit, and felt like coloring the entire entry in bright green can make it a bit difficult to read and doesn't particularly improve the results. We were thinking maybe it could just highlight the matching terms in a normal green color in a fashion similar to npm search. For example cargo search foo would highlight the term foo wherever it appears in the line.

Would you be willing to try that out? It will require a bit more work to figure out a good API for the Shell. These aren't "status" messages precisely. I don't know what that API would look like. I think it would be good to be somewhat flexible (being able to pass a string with specific parts specified with color), but I don't want to make it too complex. For example, there are crates like colored which make it easier, but I would prefer to not bring in a crate just for this. If there is a good balance of simple and flexible, that would be good.

@heisen-li
Copy link
Contributor Author

thank you. I have made the latest changes. I haven't figured out how to design test cases. However, I don't see any other commands to test the output color. It seems unnecessary.

@alexcrichton
Copy link
Member

Can you post a screenshot or two of what the search results look like?

@heisen-li
Copy link
Contributor Author

thank you, of course.
image

image

image

src/cargo/core/shell.rs Outdated Show resolved Hide resolved
desc_no_query: Vec<&str>,
query: &str,
color: Color,
justified: bool,
Copy link
Member

Choose a reason for hiding this comment

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

This is always true right now so does this need to be a parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because there are cases where color output is not supported.
image

I learned the way of the message_stderr()function.

pub fn status_stdout_part_green(
&mut self,
name_no_query: Vec<&str>,
desc_no_query: Vec<&str>,
Copy link
Member

Choose a reason for hiding this comment

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

Can you document what these arguments are? I can't figure out what these are from the signature/name of the method...

Copy link
Contributor Author

@heisen-li heisen-li Dec 23, 2021

Choose a reason for hiding this comment

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

Added explanation and changed parameter naming.

src/cargo/core/shell.rs Show resolved Hide resolved

if !desc_no_query.is_empty() {
let mut count_desc = 0;
for message in desc_no_query.iter() {
Copy link
Member

Choose a reason for hiding this comment

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

This looks to be the same loop as above, so can the code be refactored to avoid this duplication?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thank you,refactored the code.

@heisen-li
Copy link
Contributor Author

@ehuss @alexcrichton @Eh2406 Do you mind having a look when you get a chance? I want to know if I am on the right track. Thanks!

@alexcrichton
Copy link
Member

Sorry I do not personally have time to shepherd along this PR.

@ehuss
Copy link
Contributor

ehuss commented Jan 11, 2022

@qiangheisenberg Sorry for the lack of direction, but I don't think this is quite the way I was thinking. The way this is written seems to be highly specific to the needs for the search results. I was expecting something that was a little more generic that could be used by other things in the future.

For example, I think the Shell method could be something like write_stdout(text: &str, color: ColorSpec) -> CargoResult<()>. Then the search code could split the string on the matched text, and alternate between normal and green colors. There shouldn't be anything related to justification or status messages in this low-level API.

I also want to say that these reviews are taking an outsized amount of time from us. I would appreciate a little more effort on your side to understand how to approach these problems, and to respond to review comments. Alex asked why message_stdout takes a justified parameter if it is always true. The response to that was not clear, and I also don't see why it took that parameter, as I also see it always taking a true value. I also find the API in this PR a little hard to follow, and the method parameter names are not enough to make that clear.

Finally, I would expect some kind of test to validate the behavior with color. That can be done by using --color=always, and there are a few examples in the testsuite doing that.

@ehuss ehuss assigned ehuss and unassigned Eh2406 Jan 11, 2022
@ehuss ehuss added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 1, 2022
epage added a commit to epage/cargo that referenced this pull request Feb 26, 2022
@epage
Copy link
Contributor

epage commented Feb 26, 2022

I've gone ahead and created #10425 that tries to resolve @ehuss's concerns as part of an experiment for more flexible colored output for cargo-add. It works alright in this case.

bors added a commit that referenced this pull request Feb 28, 2022
feat(search): Highlight search term

This supersedes #10116.  For the requested colored-output tests, this followed the pattern of the `fix` tests which just detects whether colored output is used or not.  The `cache_messages` actually verify the output is colored but that is because it can just compare to a rustc call's output.  Getting the colored output correct by hand in a test (with all of the resets) is a bit messy and would be brittle.

This was done in an exercise in exploring ways to generalize colored output support in preparation for `cargo-add` doing some colored output as well.

I converted all output calls to use this approach, even if coloring wasn't used, for consistency.  I considered coloring the overflow message but decided to hold off on that for now (either a warning-yellow or a hint-gray).

Fixes #9918
@alexcrichton
Copy link
Member

I've r+'d #10425, so I'm going to close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add color to cargo search
6 participants