git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Ryan Zoeller <rtzoeller@rtzoeller.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC 0/1] Leading whitespace as a function identification heuristic?
Date: Fri, 25 Sep 2020 20:12:12 +0200	[thread overview]
Message-ID: <f0fab667-fb72-b15d-258b-aa437235bba4@kdbg.org> (raw)
In-Reply-To: <20200923215859.102981-1-rtzoeller@rtzoeller.com>

Am 23.09.20 um 23:59 schrieb Ryan Zoeller:
> 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

      parent reply	other threads:[~2020-09-25 18:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 21:59 Ryan Zoeller
2020-09-23 21:59 ` [RFC 1/1] xdiff: use leading whitespace in function heuristic Ryan Zoeller
2020-09-24  6:45 ` [RFC 0/1] Leading whitespace as a function identification heuristic? Junio C Hamano
2020-09-24 21:17   ` Jeff King
2020-09-24 22:01     ` Ryan Zoeller
2020-09-25  9:11       ` Phillip Wood
2020-09-25 18:43         ` Jeff King
2020-09-25 19:01           ` Phillip Wood
2020-09-25 19:05             ` Jeff King
2020-09-25 18:12 ` Johannes Sixt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f0fab667-fb72-b15d-258b-aa437235bba4@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=rtzoeller@rtzoeller.com \
    --subject='Re: [RFC 0/1] Leading whitespace as a function identification heuristic?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).