Am 02.08.2011 01:17, schrieb Junio C Hamano: > René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> writes: > >> Add a new option, -W, to show the whole surrounding function of a match. > > Thanks, will queue both patches. > > It feels somewhat dirty to take the range between the previous "funcname" > and the next "funcname" and consider it the whole function, as if there is > nothing outside the function, though. I certainly understand that this is > a natural and unfortunate consequence that "funcname" is a mechanism > designed to mark only the _beginning_, and we didn't have any need for a > mechanism to mark the _end_. > > I am not complaining; just making an observation. I do not offhand have a > suggestion for improving this, and I think the obvious "then let's come up > with another configuration to mark the end" is not an improvement but > making things worse, so... A certain amount of dirtyness is unavoidable unless we use a real parser. Apropos, labels are function boundaries as well, so there we have another limitation (i.e. we won't get a function whole if it contains labels without leading whitespace). Ideally I'd like to see the whole function text up to the closing brace but including any leading comments, if present. Which is even more complicated, of course. For C-style and Shell files, /^}/ would probably suffice as a regex to find function endings.. First I'm curious to see how useful the simple start-to-start heuristic is, though. Even the -[ABC] options are kind of fuzzy -- how do you know the number is high enough before running grep? Let's see how far this quick and dirty approach to present a smarter context can take us. René -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html