2. write a script to concatenate all the code files in a folder, separated by filenames.
3. pipe that result to your editor.
4. use your editor's "find" functionality.
By reading the entire source code in a single file, you have global knowledge of the entire codebase. All the information is available to you. I suggest you try it before dismissing the idea, as I once did.
https://github.com/shawwn/scrap is what I use. `codefiles | grep js$ | xargs merge | ft js` will open all javascript codefiles in vim, in JS mode. `cppfiles | xargs merge | ft cpp` will open all C++ files in vim, in C++ mode.
Free yourself from the loop of asking other people for answers. Stop that. Read code.
If you limit yourself to "projects that have good documentation," you'll miss out on 90% of the interesting code in the world.
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.
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.
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.
I regularly read and understand 50,000+ line codebases with this technique. Again, I suggest trying it before dismissing the idea. A good IDE is nice, when they work, but this fallback has worked 100% of the time.
CLion is for C++. PyCharm is for Python. Webstorm is for JS. But Vim is for everything.
To put it differently: how often do you use ripgrep on a large codebase? If the answer is "often," then every time you switch to your terminal, you're losing context about the code. No wonder it's impossible to understand when you're having to read code fragments every few minutes. Read the whole code.
No argument against the one code file thing because I think it’s a great idea. But a quick comment on the JetBrains suite:
With the right plugins Intellij Ultimate is also for everything (just like Vim uses language plugins) and then you get all the benefits of the modern IDE. Intellisense, search, replace, refactor, find usage, type inference, etc
I’m not saying vim cannot do this but Intellij is now my preference for everything and I don’t feel the need for merging everything in one file for analysis because I can jump around to definitions/usages easily.
Yeah, that's valid. `idea .` seemed to work occasionally back when I tried. But what I ran into was, you often want to install specific plugins for JS, and specific plugins for Python, etc. On my laptop, the result was that IDEA started taking like ... 4 minutes to fully load a codebase. So I just gave up.
But IntelliJ is wonderful in general. Maybe others will have more luck.
Why would you switch to the terminal to use grep from Vim? :grep works perfectly well, and is more convenient than search in a flat file (better context for matches, quickfix list instead of n/N nonsense).
I haven't used it, but there is WebStorm [1]. Visual Studio Code also also has fairly good jump to definition/find usages, thanks to the fact that it has a typescript compiler built in, which allows it to perform analysis of JavaScript projects as well.
2. write a script to concatenate all the code files in a folder, separated by filenames.
3. pipe that result to your editor.
4. use your editor's "find" functionality.
By reading the entire source code in a single file, you have global knowledge of the entire codebase. All the information is available to you. I suggest you try it before dismissing the idea, as I once did.
https://github.com/shawwn/scrap is what I use. `codefiles | grep js$ | xargs merge | ft js` will open all javascript codefiles in vim, in JS mode. `cppfiles | xargs merge | ft cpp` will open all C++ files in vim, in C++ mode.
Free yourself from the loop of asking other people for answers. Stop that. Read code.
If you limit yourself to "projects that have good documentation," you'll miss out on 90% of the interesting code in the world.