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

limit search to specific namespaces and classes #236

Closed
phipse opened this issue Nov 16, 2016 · 5 comments
Closed

limit search to specific namespaces and classes #236

phipse opened this issue Nov 16, 2016 · 5 comments

Comments

@phipse
Copy link

phipse commented Nov 16, 2016

Hi,
I'd like to be able to focus the search in a C++ code base to classes/functions in specific namespaces;
Meaning, I'd like to do something like this:

rg ns::Foo ./path/

and get a result 'class Foo' defined in namespace 'ns' ; and no results of 'class Foo' defined in other namespaces.

Or if I am looking for a function 'fn' in class 'Bar', I'd like to do:

rg Bar::fn ./path/

and get not only a result for a member function definition outside the class declaration, which already contains the string "Bar::fn", e.g.:

void Bar::fn(int a, int b) { ... }

but also results for a function definition 'fn' inside a class declaration e.g.:

class Bar {
void fn(int a, int b) { ... }
};

Is something like this already possible?

@BurntSushi
Copy link
Owner

BurntSushi commented Nov 16, 2016

This requires language aware search. As of right now, ripgrep is a general purpose line oriented search tool. Language aware search is not something ripgrep currently supports, and it's not really on the horizon either. Language aware search would require significant effort.

The closest thing to your request (and it's admittedly not that close) is #95, which is about adding fulltext search to ripgrep. It doesn't have to be strictly language aware, but having language aware tokenizers could potentially improve the quality of results. However, language aware tokenizers is a totally different story than actually understanding language level concepts like classes or namespaces.

Maybe something like this will appear in ripgrep (or a related tool) some day, but I'd expect that time scale to be measured in years. So I'm just going to close this for now.

@BurntSushi
Copy link
Owner

@phipse Out of curiosity, is there another tool you use that has this feature? (Other than something like a specific C++ IDE plugin or something.)

@phipse
Copy link
Author

phipse commented Nov 16, 2016

No, there isn't, unfortunately. Is there a way to match the corresponding closing brace using ripgrep, such that I can search for "namespace Foo {.*}" ?

In my head it's basically this:

for each file in `rg -l "namespace Foo"`:
do
rg "class Bar" file
done;

and in between count the opening and closing braces to limit the content of file to the namespace.
A language aware tokenizer would be nice to have, but I think for my use case this might also be a little bit over the top.

@BurntSushi
Copy link
Owner

Is there a way to match the corresponding closing brace using ripgrep, such that I can search for "namespace Foo {.*}" ?

ripgrep is line-oriented. It doesn't support multi-line search. Stated more clearly: no part of a regex can ever match a \n.

and in between count the opening and closing braces to limit the content of file to the namespace.

In normal operation, ripgrep never actually holds the contents of an entire file in memory (unless it happens to be small enough to fit into ripgrep's buffer).

A language aware tokenizer would be nice to have, but I think for my use case this might also be a little bit over the top.

But the specification you've described is language aware. (I only mentioned a language aware tokenizer in the context of fulltext search. I agree that it is both insufficient and overkill at the same time for your problem.) More to the point, the implementation path you've described is also insufficient. You can't just count braces because they can appear inside of strings or comments where they have no significance.


I will say this: I do continue to noodle on the possibility of multi-line search, because it is occasionally useful, and it could possibly bail you out too in a problem like this. There are unfortunately significant performance trade offs that come with multi-line search though (both time and memory), so it needs careful thought and probably won't happen soon.

@phipse
Copy link
Author

phipse commented Nov 16, 2016

Alright, thanks a lot for your thoughts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants