Re: [PATCH 0/4] grep: add more information to hunk separators

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

Am 26.03.2012 07:14, schrieb Junio C Hamano:
> Mark Lodato<lodatom@gmail.com>  writes:
>
>> Originally, I had envisioned also moving the function name (`-p') to the hunk
>> header, similar to the diff context line.  For example:
>>
>>      -- git.c:570 -- int main(int argc, char argv)
>>                      printf("usage: %s\n\n", git_usage_string);
>>                      list_common_cmds_help();
>>                      printf("\n%s\n", git_more_info_string);
>>
>> After implementing this feature, I was not happy with the result and
>> subsequently removed it.  To me, the output was too cluttered and the line
>> number was ambigous.  For example, in the above, it is not obvious to me that
>> line 570 is the "printf" line and not the "int main" line.  Still, if you
>> would like to see the patch to implement this feature, please let me know.
>
> The worst part of all of the above is that the output becomes utterly
> ambiguous and the reader cannot tell if "-- git.c..." came because the
> file had such a line that begin with two dashes in it and grep found it,
> or it is your output format embellishment. It is obvious that these are
> not meant to be machine parseable, but if the goal is to make the output
> more useful to the humans, then it may be a better approach to come up
> with a front end that reads our machine readable output and shows output
> with its own embellishments. You could even make it an interactive front
> end.

Human readers can differentiate between contents and heading by color; 
separators are cyan by default.

A separate frontend would probably have to implement match highlighting 
again.  That's not too hard, but a bit sad.

> In other words, I am not yet convinced this belongs to "git grep" proper.

All in all, I'm not sure either.  But I think the idea to deduplicate 
the meta-information and give found content more screen real estate is a 
good one in general.

René