Bert Wesarg [off-list ref] writes:
quoted
Can you give a concrete example of how you'd use this? I'm not sure I
understand the described use case.
I parse the output of compiling a file, there may be warnings or even
errors, I collect the given line numbers, and then call 'git grep -p
-C -n (-@ <lno>)+ -- <path>' to show me what these warnings are about.
What would you do next after doing that? Open the file in your editor and
jump to the line found by the grep? Oh, wait, that's the same line as
your compiler already found for you.
And when you open the file in your editor, doesn't it show offending line
in the middle of the screen? You can even fix it up right there. Isn't
your editor wonderful?
The extra "grep -@" step in-between looks like a totally made-up use case
that is not interesting nor convincing.
On Mon, May 2, 2011 at 18:46, Junio C Hamano [off-list ref] wrote:
Bert Wesarg [off-list ref] writes:
quoted
quoted
Can you give a concrete example of how you'd use this? I'm not sure I
understand the described use case.
I parse the output of compiling a file, there may be warnings or even
errors, I collect the given line numbers, and then call 'git grep -p
-C -n (-@ <lno>)+ -- <path>' to show me what these warnings are about.
What would you do next after doing that? Open the file in your editor and
jump to the line found by the grep? Oh, wait, that's the same line as
your compiler already found for you.
A build run will probably produce many warnings or errors (think of
-j) for many files, so you need to handle more than one file. After
the build run, you get a list of files which have warnings/errors,
selecting one of the files will give you the original messages
including the grep -@ output, from there you can select which message
you want to consider opening in the editor, so grep -@ helps you in
your decision what to open in your editor. If this would all be in a
terminal your original output would be far away anyhow.
I haven't implemented this 'workflow' for the terminal, but for a GUI,
so I can jump to original output easily and open the file in the
editor easily too. Prior to this I did this all on the command line,
but with recursive make this become too cumbersome.
And when you open the file in your editor, doesn't it show offending line
in the middle of the screen? You can even fix it up right there. Isn't
your editor wonderful?
The extra "grep -@" step in-between looks like a totally made-up use case
that is not interesting nor convincing.
Visually parsing many warnings/errors of one file by successively
jumping to the offending line in the editor doesn't sound very
productive to me, but having all offending lines with context and
--show-functions in one output does sound.
Bert