-
Notifications
You must be signed in to change notification settings - Fork 111
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
[question] Un-ignore flag? #342
Comments
Thanks for asking. You can undo the Most long options permit a More suggestions:
|
I've added a sentence "Long options may start with '--no-' to disable, when applicable" when executing I agree that typing What do you think? Or perhaps add I think it is a good idea to also add |
The extra clarification in the manual is nice. What was surprising to me, is that the --include/exclude doesn't seem to affect --ignore-files, maybe that should be clarified as well. I kind of expected patterns/globs to have a single map internally. What I like about rg' "-u" option is that very often when used with --ignore-files (and other exclude rules), you're deliberating ignoring sizable chunks of a project because there's usually stuff you don't want to see most of the time. But sometimes, you search for something and you expect results and you suspect you're hiding it due to some exclusion, which you don't know. In some project it might be a hidden configuration file (.github to name one which would require -.), some generated makefile (via .gitignore..), maybe an exclude glob in .ugrep. So which one do I toggle to be sure I'm not ignoring anything? rg repeating -u progressively unignoring stuff does answer this pretty well. Which stuff is unignored first is debatable (depends on what you're doing), but I know that after 3 I'm searching everything. I'm mentioning this because I was using the ack-grep/silversearcher before, and due to this I frequently resorted to plain "grep" when I was in doubt some of my exclusions could ignore stuff I was expecting. It's also true I could just add a shell alias to unexclude all options, but appending -u to the current line is very ergonomic.. |
I exactly understand that when we are in doubt we want to search all files, for example after nothing is returned as a match, but we expected something nonetheless or we want to make sure nothing matched. Searching all files will give this assurance that nothing was found. How about:
This new option offers flexibility. To really search everything, use I deliberately picked Because we have a short option |
I personally like how this would work. Maybe we want to see if somebody else has some extra opinion on the behavior? |
Ping @leahneukirchen @pikumar @stephentalley if any of you is interested in following this discussion and perhaps comment on a new |
Sounds useful this way! |
About Also, in my opinion, using a special character like |
I would consider this typical? I didn't really see this difference between short/long options "in the wild". Generally the rightmost argument always overrides a previous one (incidentally, this is what allows shell aliases to work ok, as you can override previous behavior). |
True, but surely not all options behave that way. Most options are orthogonal, complimentary, like The |
Working on finalizing version 5 to include this improvement. Version 5 has a regex engine revision to increase search speed, which takes time to verify and test. |
I will name the new option The new option will be available with version 5 to be released very soon. |
Implemented. |
Coming from ripgrep, I'm wondering if there is a way to quickly reset the "ignore" rules with a command flag? (same as ripgrep's -u flag, for example).
I'm using a couple of "ignore-files" rules in my
.ugrep
config, which are helpful to exclude non-interesting things in a project. Occasionally though I want to search for all files and drop any previous ignore rules, but still preserve my other options in.ugrep
.ripgrep offers the "-u/--unignore" flag, which when used once resets the ignore list, repeated also searches for hidden files, exactly for this sort of usage scenario.
Is there something similar in ugrep?
The text was updated successfully, but these errors were encountered: