On Fri, Jan 13, 2017 at 10:19 AM, René Scharfe <l.s.r@xxxxxx> wrote: > Am 13.01.2017 um 17:15 schrieb Vegard Nossum: >> >> When using -W to include the whole function in the diff context, you >> are typically doing this to be able to review the change in its entirety >> within the context of the function. It is therefore almost always >> desirable to include any comments that immediately precede the function. Do we need a small comment in the actual code to hint at why we count upwards there? >> >> This also the fixes the case for C where the declaration is split across >> multiple lines (where the first line of the declaration would not be >> included in the output), e.g.: >> >> void >> dummy(void) >> { >> ... >> } >> > > That's true, but I'm not sure "non-empty line before function line" is good > enough a definition for desirable lines. It wouldn't work for people who > don't believe in empty lines. Or for those that put a blank line between > comment and function. (I have an opinion on such habits, but git diff > should probably stay neutral.) And that's just for C code; I have no idea > how this heuristic would hold up for other file types like HTML. I think empty lines are "good as a first approach", see e.g. 433860f3d0beb0c6 the "compaction" heuristic for a similar thing (the compaction was introduced at d634d61ed), and then we can build a more elaborate thing on top. > > We can identify function lines with arbitrary precision (with a xfuncname > regex, if needed), but there is no accurate way to classify lines as > comments, or as the end of functions. Adding optional regexes for single- > and multi-line comments would help, at least for C. That would cover Java and whole lot of other C like languages. So a good start as well IMHO. > > René