bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

--show-c-function and --show-function-line=RE (was Re: [patch #3644] --i


From: Charles Levert
Subject: --show-c-function and --show-function-line=RE (was Re: [patch #3644] --initial-tab and 3 newly colorized items) [bug-grep]
Date: Wed, 26 Jan 2005 15:59:26 -0500
User-agent: Mutt/1.4.1i

* On Wednesday 2005-01-26 at 17:35:40 +0000, Julian Foad wrote:
> Elliott Hughes wrote:
> >On Jan 26, 2005, at 07:46, Stepan Kasal wrote:
> >>I also think that the --show*function options should eventually go in.
> >
> >are you sure? diff does a really poor job of that. something like 
> >Exuberant ctags can do a much better job, for far more languages. why 
> >not pipe the output of diff/grep into a script that adds the annotations?

Keep in mind that in the case of grep, this is a quick and dirty tool
to first locate stuff.  The "--show-function-line=RE" can be used with
shell aliases (or shell scripts) to cover different languages.


> I tend to agree.  It's undeniably useful to some people to have such a 
> feature available at the touch of a single option letter, but implementing 
> and supporting such a feature which doesn't actually work very well overall 
> is quite a high cost.

The high cost (size of the patch) is one reason I was uneasy about
submitting it at this point.  Actually, the patch can be broken in
3 parts:

  1) changes to make src/dfa.c handle several regexps (specific layer;
     "grep", "grep -E", and "grep -X awk");

  2) changes to make src/search.c handle several regexps (generic layer;
     enough for "grep -P" because of the existing properties of the PCRE
     interface, and "grep -F");

  3) changes to implement --show-c-function and --show-function-line.

Part 3 (the one that's directly visible to the user) is actually
of relatively modest size and its "lazy" behavior can have little
performance impact.  The first two parts (especially part 1) are more
important in size and the ancillary question is then:  could this work
be worth doing for other reasons (clearer internal design, ...)?


> >i have such a script for annotating patches, if anyone's interested.
> 
> Yes please.  I currently use "diff -p" for generating patches, and then 
> have a script to extract a list of the functions touched to make a log 
> message template.  It gets it wrong quite often, so I have to edit the 
> result by hand. I'd like to use your better solution.

On a somewhat related note (plug!), I have written a diff-output editor.
It is available at

  <https://gna.org/projects/ude/>
  <http://home.gna.org/ude/>

The aim is a little different.  It allows manipulation of the specific
output of GNU diff (its choice of common, old, and new lines, which is not
always the unique one possible given the input files) without changing its
semantics to make it more suitable to interpretation by a human reader.
It recomputes the "@@" lines automatically, among other things.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]