From: Mark Lodato <lodatom@gmail.com>
To: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 4/5] grep: Colorize filename, line number, and separator
Date: Sun, 28 Feb 2010 15:14:40 -0500 [thread overview]
Message-ID: <ca433831002281214q14e6e62bj54cf7227cd32873b@mail.gmail.com> (raw)
In-Reply-To: <4B890572.5040604@lsrfire.ath.cx>
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.
>> diff --git a/builtin-grep.c b/builtin-grep.c
>> + if (!value)
>> + return config_error_nonbool(var);
>
> color.grep without a value used to turn on colourization, now it seems
> to error out.
Oops, that should be "if (color && !value)". I will fix in next respin.
>> + color_parse(value, var, color);
>> + if (!strcmp(color, GIT_COLOR_RESET))
>> + color[0] = '\0';
>
> This turns off colouring if the user specified "reset" as the colour,
> right?
Yes.
> Interesting optimization, but is it really needed? Perhaps it's
> just me, but I'd give the user the requested "<reset>text<reset>"
> sequence if she asked for it, even if it's longer than and looks the
> same as "text" alone.
The problem is that there's no way to say "no color". A blank value
and "reset" both come to the same thing. I would rather have as
little markup as possible in the output, and this tweak is very
simple. While this is not strictly necessary, it does make the output
identical to the pre-patch output if you disable all the new colors
(just grep.color.separator, by default.)
>> + }
>> + else
>
> } else
Oops, thanks.
>> + if (opt->null_following_name) {
>> + sign = '\0';
>> + opt->output(opt, &sign, 1);
>> + } else
>
> if (opt->null_following_name)
> opt->output(opt, "", 1);
> else
Personally, I find your suggestion less readable. My version is only
one line longer but makes the code completely obvious, whereas the
one-liner requires a second of thought. Anyone else care to comment
on this?
next prev parent reply other threads:[~2010-02-28 20:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-27 4:57 [PATCH 0/5] color enhancements, particularly for grep Mark Lodato
2010-02-27 4:57 ` [PATCH 1/5] Allow explicit ANSI codes for colors Mark Lodato
2010-02-27 8:51 ` Jeff King
2010-02-27 18:24 ` Mark Lodato
2010-02-27 21:21 ` Junio C Hamano
2010-02-28 2:56 ` [PATCH] color: allow multiple attributes Junio C Hamano
2010-02-28 12:20 ` Jeff King
2010-02-28 18:16 ` Junio C Hamano
2010-02-28 18:33 ` Jeff King
2010-02-27 4:57 ` [PATCH 2/5] Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_* Mark Lodato
2010-02-27 4:57 ` [PATCH 3/5] Remove reference to GREP_COLORS from documentation Mark Lodato
2010-02-27 4:57 ` [PATCH 4/5] grep: Colorize filename, line number, and separator Mark Lodato
2010-02-27 11:43 ` René Scharfe
2010-02-28 20:14 ` Mark Lodato [this message]
2010-02-28 22:26 ` Michael Witten
2010-03-02 1:49 ` Mark Lodato
2010-03-02 6:43 ` Michael Witten
2010-03-03 4:26 ` Mark Lodato
2010-03-03 4:49 ` Miles Bader
2010-02-27 11:53 ` René Scharfe
2010-02-27 17:08 ` Junio C Hamano
2010-02-28 20:15 ` Mark Lodato
2010-02-28 19:29 ` Junio C Hamano
2010-02-28 20:39 ` Mark Lodato
2010-02-27 4:57 ` [PATCH 5/5] grep: Colorize selected, context, and function lines Mark Lodato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca433831002281214q14e6e62bj54cf7227cd32873b@mail.gmail.com \
--to=lodatom@gmail.com \
--cc=git@vger.kernel.org \
--cc=rene.scharfe@lsrfire.ath.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).