Before you know the function’s name
jevgrep made me think about the moment a question about behavior turns into a concrete symbol you can follow.
Where does that code live?
Suppose you need to change request retries in an unfamiliar repository. You know the symptom: when a server takes too long to respond, the request is sent again. You do not know the name of the function responsible.
You could search for retry. Imagine finding configuration, tests, and comments, while the request itself sits behind a shared client. After reading every occurrence, you might still be unsure whether your request takes that route.
What you want to ask a colleague is simple: “Where do we send it again after a timeout?”
jevgrep is a tool for finding code through questions like that. Its README describes returning relevant files, reading leads, and verbatim source with line locations. I have not installed it for a hands-on review. Reading its documentation and published output made me picture this search through unfamiliar code.
It feels a little like entering a library without a book title. You can ask for “the one where the main character lives the same day over and over.” If you must know the title before searching, you are stuck circling the question.
After opening the first page
I liked that the result includes actual source. The published output example shows a short method forwarding to another class’s method, along with the file containing that method. There is something to follow from the current line into the next file.
I would want that handle in the hypothetical retry task. “Look in the shared client” is helpful. Seeing which function to open makes the next move clearer.
Suppose the first excerpt gives us a name: sendWithPolicy. We can now find its callers. The vague question has acquired a precise search term.
A retry branch in that function does not finish the explanation of our request. We also need to read the policy supplied by the caller. Two routes could use the same client while only one enables retries.
In this example, finding the function makes the question smaller. “Where do retries happen?” becomes “Which policy does this call pass?” We have a way to choose the next line to read.
That is the help I would want from a code-search tool: a place to keep reading, rather than a demand that I already understand the repository.
Different routes through the same name
jevgrep’s architecture document explicitly limits what parsing and reading leads establish: they are not proof of runtime dispatch. I read this as a reason to connect the location of code with how execution selects it.
Inherited methods, environment-specific implementations, and options passed at the call site make that distinction tangible. The same name can lead you to different code depending on the object and configuration involved.
After the first result, familiar work resumes: find references to the exact symbol, open the caller, and trace where its configuration comes from. A search can begin with a description of behavior and still need precise names partway through.
An empty result needs context too. We need to examine the scope of the question and the search. The documentation says reaching a discovery budget is reported as partial discovery. That gives us a reason to narrow the question or root and try again. An empty list alone is too little to conclude that a feature is absent.
If the function and path are already known, opening the file directly may be enough. There is no need to visit the library desk every time. Once you know the shelf, you can walk there.
At least one name to follow
I imagine the note I would leave on this hypothetical task. Instead of “found relevant code,” I would briefly trace the request through its calls to the selected policy, leaving locations the next person can reopen.
If I only read static source, the note should stop there. Observations from actually running the request belong in a separate record. Likewise, reading these documents does not let me claim that I verified retries in a particular repository.
Still, we have moved. A question that could not get started without a name now has one name to pursue.
We can search for sendWithPolicy. Which caller brings our request here?