git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH/RFC 0/4] grep: support to match by line number

From
Bert Wesarg <bert.wesarg@googlemail.com>
Date
May 2, 2011, 19:14 UTC
Message-ID
<BANLkTi=jABd5+_R-5SjhR163WV=TF1wbmQ@mail.gmail.com>
In-Reply-To
<7v7ha9oxss.fsf@alter.siamese.dyndns.org>
On Mon, May 2, 2011 at 18:46, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>>> 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.

Show 9 quoted lines
>
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 16 of 22 in “grep: support to match by line number”
  1. 0/4 grep: support to match by line numberBert Wesarg, May 2, 2011
  2. 1/4 grep: prepare for re-using the space of the regexp member in struct grep_patBert Wesarg, May 2, 2011
  3. 2/4 grep: pass current line number down to match_one_patternBert Wesarg, May 2, 2011
  4. 3/4 grep: introduce pattern which matches at line numberBert Wesarg, May 2, 2011
  5. 4/4 grep: provide option to match line numberBert Wesarg, May 2, 2011
  6. Thiago FarinaMay 2, 2011
  7. Bert WesargMay 2, 2011
  8. Thiago FarinaMay 2, 2011
  9. Bert WesargMay 2, 2011
  10. Junio C HamanoMay 2, 2011
  11. Thiago FarinaMay 2, 2011
  12. Bert WesargMay 2, 2011
  13. Sverre RabbelierMay 2, 2011
  14. Bert WesargMay 2, 2011
  15. Junio C HamanoMay 2, 2011
  16. Bert WesargMay 2, 2011
  17. Junio C HamanoMay 2, 2011
  18. Junio C HamanoMay 2, 2011
  19. Jakub NarebskiMay 2, 2011
  20. Bert WesargMay 2, 2011
  21. Junio C HamanoMay 2, 2011
  22. Bert WesargMay 2, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.