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

Re: [PATCH 4/5] grep: Colorize filename, line number, and separator

From
Michael Witten <mfwitten@gmail.com>
Date
Feb 28, 2010, 22:26 UTC
Message-ID
<b4087cc51002281426m126a0c07l9f4a38088d0146b1@mail.gmail.com>
In-Reply-To
<ca433831002281214q14e6e62bj54cf7227cd32873b@mail.gmail.com>
On Sun, Feb 28, 2010 at 14:14, Mark Lodato <lodatom@gmail.com> wrote:
Show 14 quoted lines
> On Sat, Feb 27, 2010 at 6:43 AM, René Scharfe
> <rene.scharfe@lsrfire.ath.cx> wrote:
>> Am 27.02.2010 05:57, schrieb Mark Lodato:
>>> 1. With --name-only, GNU grep colors the filenames, but we do not.  I do
>>>    not see any point to making everything the same color.
>>
>> I guess they did it for consistency, so when you see "magenta" you think
>> "filename", and because it can be turned off with a switch.  With your
>> patch all filenames are coloured the same, too, by the way: using the
>> default foreground colour. :)
>
> Yes, I think I understand the reasoning, but to me it is very
> annoying.  However, if there is a consensus that we should follow GNU
> grep in this regard, I will do it.

I'm in favor of colorizing the output even when just one piece of information is presented. If I turn on colorization, then there should be colorization; my brain would expect it, especially when I first grep without --name-only and then turn on --name-only after getting results that I like.

Of course, I bet you find colorizing the filenames a nuisance because you don't care to pipe the relevant escape sequences to other commands. On that note, it would be nice to have something like GNU's --color=(auto|yes|no) with `auto' as the default for a plain --color.

As a compromise (and perhaps as an improvement), perhaps only the basename of the filename should be colorized when --name-only is used; that way, colorization is still being used to differentiate different data, and the rest of the path is usually not that interesting anyway. However, for consistency, I would still think it wise to colorize the dirname portion with `color.grep.filename', but color the basename portion with `color.grep.match' (as though the basename portion is the text being matched).

Sincerely, Michael Witten

Previous: Mark LodatoNext: Mark Lodato
Message 15 of 25 in “color enhancements, particularly for grep”
  1. 0/5 color enhancements, particularly for grepMark Lodato, Feb 27, 2010
  2. 1/5 Allow explicit ANSI codes for colorsMark Lodato, Feb 27, 2010
  3. Jeff KingFeb 27, 2010
  4. Mark LodatoFeb 27, 2010
  5. Junio C HamanoFeb 27, 2010
  6. color: allow multiple attributesJunio C Hamano, Feb 28, 2010
  7. Jeff KingFeb 28, 2010
  8. Junio C HamanoFeb 28, 2010
  9. Jeff KingFeb 28, 2010
  10. 2/5 Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_*Mark Lodato, Feb 27, 2010
  11. 3/5 Remove reference to GREP_COLORS from documentationMark Lodato, Feb 27, 2010
  12. 4/5 grep: Colorize filename, line number, and separatorMark Lodato, Feb 27, 2010
  13. René ScharfeFeb 27, 2010
  14. Mark LodatoFeb 28, 2010
  15. Michael WittenFeb 28, 2010
  16. Mark LodatoMar 2, 2010
  17. Michael WittenMar 2, 2010
  18. Mark LodatoMar 3, 2010
  19. Miles BaderMar 3, 2010
  20. René ScharfeFeb 27, 2010
  21. Junio C HamanoFeb 27, 2010
  22. Mark LodatoFeb 28, 2010
  23. Junio C HamanoFeb 28, 2010
  24. Mark LodatoFeb 28, 2010
  25. 5/5 grep: Colorize selected, context, and function linesMark Lodato, Feb 27, 2010

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.