-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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 warning if nothing was searched #1762
Add warning if nothing was searched #1762
Conversation
Please don't delete PRs or issues. I'm really surprised GitHub gives you the ability to delete issues/PRs filed on another repo. Please don't do that. Because you deleted it, we've now lost some historical context and some helpful info on a false start. Sure, the PR might have been wrong, but we don't just sweep wrong things under the rug. We learn from them. Aside from that, you shouldn't have needed to open a new PR. For a small change like this, it's enough to keep it inside a single commit. When you make a change, just amend the commit. ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks correct to me! Have you tried it? Does it work?
I think adding some tests would be a good idea. They should go in tests/feature.rs
. I think you'll find assert_non_empty_stderr()
helpful in this case. Here's an example of another test that uses it:
Lines 44 to 47 in a6d0547
// See: https://github.com/BurntSushi/ripgrep/issues/1 | |
rgtest!(f1_unknown_encoding, |_: Dir, mut cmd: TestCommand| { | |
cmd.arg("-Efoobar").assert_non_empty_stderr(); | |
}); |
Take a look at other tests in that file to see how to setup directory trees and what not.
Sorry, I got confused with the whole fork thing on github. Since there was only 1 commit, I deleted the branch on my fork, not realizing that would close the PR. I had intended to just force push my new commit to the same branch name. |
Yes, I've tried it with this setup of files:
Then I do Thanks for the hints, I'll look into the tests later! |
@BurntSushi I added a test case for the warning and it passes. But another test ( I think it's because the case being tested there throws an exception and therefore never triggers my |
@BurntSushi Ping just in case you hadn't seen this |
This was once part of ripgrep, but at some point, was unintentionally removed. The value of this warning is that since ripgrep tries to be "smart" by default, it can be surprising if it doesn't search certain things. This warning covers the case when ripgrep searches *nothing*, which happens somewhat more frequently than you might expect. e.g., If you're searching within an ignore directory. Fixes #1404, Closes #1762
This was once part of ripgrep, but at some point, was unintentionally removed. The value of this warning is that since ripgrep tries to be "smart" by default, it can be surprising if it doesn't search certain things. This warning covers the case when ripgrep searches *nothing*, which happens somewhat more frequently than you might expect. e.g., If you're searching within an ignore directory. Note that for now, we only print this message when the user has not supplied any explicit paths. It's not clear that we want to print this otherwise, and in particular, it seems that the message shows up too eagerly. e.g., 'rg foo does-not-exist' will both print an error about 'does-not-exist' not existing, *and* the message about no files being searched, which seems annoying in this case. We can always refine this logic later. Fixes #1404, Closes #1762
This was once part of ripgrep, but at some point, was unintentionally removed. The value of this warning is that since ripgrep tries to be "smart" by default, it can be surprising if it doesn't search certain things. This warning covers the case when ripgrep searches *nothing*, which happens somewhat more frequently than you might expect. e.g., If you're searching within an ignore directory. Note that for now, we only print this message when the user has not supplied any explicit paths. It's not clear that we want to print this otherwise, and in particular, it seems that the message shows up too eagerly. e.g., 'rg foo does-not-exist' will both print an error about 'does-not-exist' not existing, *and* the message about no files being searched, which seems annoying in this case. We can always refine this logic later. Fixes #1404, Closes #1762
Ok, another attempt at fixing #1404.
I somehow messed up the other PR in the Github UI, not sure how. You can delete it.
Let me know if this is on the right track, and I'll look into tests.