[sillysaurusx]

This recommendation often leads to confusion. Every time you search for something using ag or rg, you're losing all the context around the code. And yeah, -C 10 is a thing, but it's a shadow of having the actual code in an actual editor.

It's remarkable how offensive this idea is to people. It's not like I came up with the idea this morning. I've been reading hundred-thousand line codebases for many, many years this way. It's how I studied and understood the original bitcoin codebase.

But, you know, if you really want to be stuck in the loop of "ok, this file calls Foo, let me switch to terminal and search for Foo... Ok, now I'll open that file and read it.. Oh it calls Bar, I'll search for bar..." then feel free.

And yeah, an IDE is the antidote. If it's a JS project, use `webstorm .`. For python, use `charm .` Unfortunately `clion .` doesn't seem to work for C++ codebases -- you have to "import" the code first, which is highly annoying and generates extra CMakeList.txt flies. VSCode might be fine and automatic and perfect go-to-definition functionality even for template metaprogramming; I don't know.

But I do know that the technique I've described above will work 100% of the time.

[quanticle]

That's why you use a plugin that integrates ag or ripgrep into your editor so that you can see the context in your editor as you search.

[sillysaurusx]

Sure, that's fine. Personally, I hate dealing with vim plugin nonsense, and especially with getting vim environments working on a remote server inside tmux. But whatever works.

[quanticle]

The other reason I don't favor this approach is that it totally ignores the fact that the organization of files and filenames also give you valuable semantic information. If I had a library, that, for some insane reason, decided to scramble its source across a gigabyte of filenames generated by a hash function, then I would definitely choose your approach. But most libraries (even horrible internal libraries) aren't like that. The name and location of files allows one to better understand whether the search result is relevant or not. As a cheap example, with `find` or `ag`, I can easily exclude the `test` folder, so that I don't have to deal with usages in unit tests when I'm trying to understand a piece of library code. But, if I'm modifying that code, being able to see unit test results is valuable, because it lets me know which test files I have to update.

With your approach, I get the full list of results, whether I want it or not.

[petepete]

Plus, if you want to just jump based on keywords ctags is more than enough and support is built into most decent editors.