-
-
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
VSCode expected search behaviour is incompatible with Ripgrep's actual behaviour #2606
Comments
I'm not really sure what is to be done here. The entire point of I'll note that there are many open issues with respect to ignore, and you are not the first one to bring up the occasionally non-ideal interaction between The main problem here is that ripgrep's filtering logic has a ton of surface area right now with oodles of little knobs to control its behavior in corner cases. (e.g., |
I'll note that, VS Code aside, the "proper" way to do something like this should be to do In any case, there is probably also some stuff to figure out on the VS Code side here as well. But it's not a goal for ripgrep to start solving UX problems that VS Code has, and "upstream should just figure it out and add a new feature" is not really how I work. |
Yeah I don't see this as a bug in Ripgrep at all, it's just working as designed.
Of course. I'm a bit disappointed with the way the VSCode maintainers have just closed the issue :(. I wasn't sure if you personally had been involved at all in getting Ripgrep into VSCode but it sounds like not...
Yeah this sounds like it would be a big improvement. Perhaps a system like this: trait PathMatcher {
fn matches_path(&self, path: &Path) -> bool;
fn can_skip_directory(&self, path: &Path) -> bool { false }
}
struct GitIgnoreMatcher;
impl PathMatcher for GitIgnoreMatcher { .. }
struct RegexMatcher;
impl PathMatcher for RegexMatcher { .. }
struct NotMatcher;
struct AllMatcher;
struct AnyMatcher;
... more ... If interacting with Ripgrep procedurally, then you would pass in a structured (eg. json) value describing a set of matchers, so you could say "all(RegexMatcher, GitIgnoreMatcher)` or similar. If interacting with Ripgrep manually then there could be a more friendly set of command line args that ultimately just get mapped to the structured representation. If interacting with Ripgrep as a crate, you could even implement your own custom PathMatchers. |
I didn't do any of the work, but I did work with them during the initial push to get ripgrep included to land some stuff that they found very useful. Things like UTF-16 support and the Thanks for the code snippet. I don't have the context to really evaluate it at the moment. The main challenge is in collecting all of the various design constraints outstanding (not just this one), writing them down in one place and then figuring out how to build something that deals with it gracefully. |
See microsoft/vscode#192045 for details.
This is really a VSCode bug, but it can't easily be fixed in VSCode without changes or new features in Ripgrep.
In summary, the
-g foo
option in Ripgrep overrides .gitignore, which causes VSCode's search functionality to return incorrect results, since VSCode allows selecting both "use .gitignore" and "filter to directory".The text was updated successfully, but these errors were encountered: