Re: [RFC 0/1] Leading whitespace as a function identification heuristic?

From: Johannes Sixt <j6t@kdbg.org>
Date: Sep 25, 2020, 18:12 UTC
Message-ID: <f0fab667-fb72-b15d-258b-aa437235bba4@kdbg.org>
In-Reply-To: <20200923215859.102981-1-rtzoeller@rtzoeller.com>

Am 23.09.20 um 23:59 schrieb Ryan Zoeller:

Show 12 quoted lines

> I've recently been annoyed by git's choice of lines when invoking
> `git diff --function-context`. git isn't doing a _bad_ job per se,
> given that it's using regular expressions to parse nonregular languages,
> but in my opinion it could do better.
> 
> The issue I'm seeing is that constructs like nested functions cause
> `git diff --function-context` to stop taking lines prematurely; a line
> containing a function declaration has been reached, but it's not the one
> I'm expecting git to stop at. This results in some of the function being
> omitted from the output of `git diff --function-context`, and also
> manifests itself as the incorrect function being listed in the hunk header
> in general.

There are two mechanisms at play here:

The first is that the context above and below a point of interest is extended to the next function. This is relevant for both `git diff` and `git grep` when --function-context is specified.

The second is the determination of the hunk header. It is only relevant for `git diff`.

The purpose of the hunk header is to get an estimation of where the hunk is located. It is most helpful in this case when the closest anchor point is listed; it is not important to find where the semantically surrounding nesting context begins.

Therefore, I suggest that you aim only for the --function-context case, because there it makes sense to find the correctly nested surrounding context if possible.

-- Hannes