Re: Patch upstream Git for Elisp diff hunk headings

[Adam Spiers]

On Thu, 11 Feb 2021 at 14:42, Protesilaos Stavrou <info@protesilaos.com> wrote: 
>Dear members, 
>
>Myself and Adam Spiers (in cc) have been discussing the possibility of 
>patching Git so that it can handle Emacs Lisp diff hunk headings 
>natively.  Those headings consist of the text that follows the line 
>ranges that diff outputs.  So this: 
>
>   @@ -389,7 +390,7 @@ HEADING HERE
>
>Git produces those headings using language-specific regular expressions. 
>Elisp is not covered.  Users must thus define their own Git attributes. 
>Not doing so results in practically useless text for the heading; text 
>that does not provide an accurate sense of context. 
>
>I have noticed that Emacs' git repo includes the file ".gitattributes" 
>which instructs diffs inside of that repo to use an Elisp-aware regexp 
>present in "autogen.sh": 
>
>   git_config diff.elisp.xfuncname \
>              '^\([^[:space:]]*def[^[:space:]]+[[:space:]]+([^()[:space:]]+)'
>
>This is an improvement over the out-of-the-box Git experience. 
>
>Now the questions to this list: 
>
>1. What do you think about only targeting top-level forms? 

Thanks Prot.  To add a little bit of colour to this particular 
question, I'm thinking of cases like 

    (use-package some-package
       :config
       [... many lines of config code ...])

or many other top-level forms commonly found in users' emacs init 
files.

These would not match the regexp above, and since clearly it is 
possible to define any function or macro, the only way I can think of 
to teach git a line-based regexp for recognising the start of 
top-level forms is to make the assumption that they are not indented, 
e.g.

    git_config diff.elisp.xfuncname "^(\\(.*)$"

Indeed this is what Prot initially suggested in his original blog post 
which sparked this discussion: 

    https://protesilaos.com/codelog/2021-01-26-git-diff-hunk-elisp-org/

While of course no one is claiming that this is technically correct in 
all cases, I don't think I can actually recall ever seeing a single 
instance of a top-level form which *was* indented.  So presumably it's 
a good enough heuristic to be helpful in the vast majority of cases. 
Or at least it's more likely to be right than a heuristic which 
assumes that all top-level forms include "def" in the first symbol in 
the form, since the latter obviously fails in many common scenarios 
including the init files one mentioned above. 

Would be grateful to hear other views on this.

Thanks,
Adam