buggrep - Bugs: bug #12019, Feature: alternative color for...


You are not allowed to post comments on this tracker with your current authentication level.

bug #12019: Feature: alternative color for context lines

Submitted by:  None
Submitted on:  Fri 18 Feb 2005 08:40:38 AM UTC  
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Duplicate
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

( Jump to the original submission)

Fri 04 Mar 2005 11:56:41 AM UTC, comment #6:

Please move any further discussion to patch #3644.

Charles Levert <charles_levert>
Thu 03 Mar 2005 12:46:23 PM UTC, comment #5:

<<<But it occurred to me that it would help if non-matching lines preceding matching lines are colored differently than non-matching lines following matching lines.>>>

What about middle non-matching lines between two matching lines so close to one another that everything stays in one chunk? Introducing a third non-matching-line color for this situation would necessitate new logic solely for identifying it in grep, and that crosses the too-much-bloat limit. (The only color that actually required new logic was the first one that's already in stable releases, that for matching text; everything else was already well identified in the code and was just waiting to be colorized.) This proposition does not seem practical to me. Besides, our brain can readily tell if something comes before or after a match; it doesn't need different colors for that very specific information (beyond having already used colorizing to set non-matching lines apart).

<<<it seems the only case when text would be unreadable on an XTerm...>>>

I have tried your proposed settings on different terminals. On my xterm, bold white (37;1) on default white background is still two identical colors. On my Linux console, bold black (30;1) on default black background is also two identical colors. Maybe we don't have the same versions of xterm or the same hardware for text consoles, but I can't be alone with the ones I have, so both these proposed bold colors are not acceptable as default foregrounds to use in GREP_COLORS.

As I stated before, my personal taste (and it's only that) tells me that setting a background for something does not make it look understated when it's supposed to. Remember that the remaining columns after the end of the actual file content for a non-matching line will still be in the default background.

I prefer leaving this choice up to the user.

Charles Levert <charles_levert>
Thu 03 Mar 2005 08:45:18 AM UTC, comment #4:

Thanks very much, this sounds very good!

Pity that the shell has no way to tell the actual colors of the terminal in which it is running, and that different terminals render colors differently. Perhaps we should choose a default that works for the most common terminal setup, rather than one that does nothing. This saves some trouble for some of the users. For example, if the default is white-on-black Xterm, then use white (37) as default.

Coloring non-matching text on matching lines may be useful, but I'm not sure how often.

But it occurred to me that it would help if non-matching lines preceding matching lines are colored differently than non-matching lines following matching lines.

Of course, this makes it even harder to find good colors to use. I suggest bold-black (30;1) and white (37;1) on default background. They look OK (gark-grey and light-grey) even on my black-on-white XTerm. Correct me if I am wrong, but it seems the only case when text would be unreadable on an XTerm is if the default background is very close to one of those colors (the other would still look OK). In my experience, most people use either black or white background on their terminals.

Or, use a dafault of grey background (30;47) for non-matching text on matching lines, black on preceding lines and bold-black on following lines (both on the default background).

Again, I appreciate your work, thank you!

Sun 20 Feb 2005 02:34:52 AM UTC, comment #3:

The implementation in patch #3644 is done.

This bug can now be closed.

Charles Levert <charles_levert>
Fri 18 Feb 2005 03:51:23 PM UTC, comment #2:

I will implement a "cx" capability in GREP_COLORS as part of patch #3644.

There is just one minor issue, however. The chosen color setting for this needs to look understated.

The highlights defined so far set only the foreground, not the background. There are only four colors that will look good on both light and dark backgrounds (both of which we must account for), they are all already taken by other highlights, and none of them is understated. Otherwise, setting the background does not look understated at all if it happens to be different from the default background. In 8-color mode which we must assume, there is no gray per se, only white (37) which is often rendered as gray (whereas bold white (01;37) is often rendered as true white). This gray looks understated compared to a true white foreground on a dark background, if that is the terminal's default pair, but it looks invisible if the default is black foreground on light background.

Therefore, long story short, I propose to implement the new "cx" capability with a default of "" (which will produce "\33[m" before each new context line). That would leave it up to the user (or the packager) to define it as something else as part of a consistent whole color theme.

Would this be ok with the (anonymous) submitter of this bug and with anyone else?

Would anyone like another capability with empty default for the non-matching text of matching lines (say, "ml"), while I am at it, or would that be too much? (It wouldn't be much harder to implement.)

Charles Levert <charles_levert>
Fri 18 Feb 2005 01:23:08 PM UTC, comment #1:

We are going to accept patch #3644, so an ideal way would be to enhance the patch to implement this feature.

Stepan Kasal <kasal>
Project Member
Fri 18 Feb 2005 08:40:38 AM UTC, original submission:

Context lines shown using the --B, --A and --C options could be colored differently than lines containing matches, for example in grey. This would make output easier to read, especially output wider than the screen. The color could be controlled using a new environment variable GREP_CONTEXT_COLOR, similarly to GREP_COLOR.



No files currently attached


   patch dependencies.

Items that depend on this one: None found


CC list is empty


Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.


Please enter the title of George Orwell's famous dystopian book (it's a date):



Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
Fri 04 Mar 2005 11:56:41 AM UTC charles_levert StatusNone => Duplicate
    Open/ClosedOpen => Closed
Fri 18 Feb 2005 01:26:14 PM UTC kasal Dependencies- => Depends on patch #3644

Back to the top

Powered by Savane 3.3