From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
Markus Heidelberg <markus.heidelberg@web.de>,
git@vger.kernel.org
Subject: Re: [PATCH 1/2] color: make it easier for non-config to parse color specs
Date: Sun, 18 Jan 2009 18:45:00 +0100 [thread overview]
Message-ID: <49736A9C.1040601@lsrfire.ath.cx> (raw)
In-Reply-To: <20090118172802.GA17434@coredump.intra.peff.net>
Jeff King schrieb:
> On Sun, Jan 18, 2009 at 06:10:36PM +0100, René Scharfe wrote:
>
>>> - right now, it is implemented in terms of color_parse().
>>> But it would be more efficient to reverse this and
>>> implement color_parse in terms of color_parse_mem.
>> Thusly?
>
> Yes, except for the bugs you introduced. :)
Eeek! :)
>> +void color_parse_mem(const char *value, int len, const char *var, char *dst)
>> +{
>> const char *ptr = value;
>> int attr = -1;
>> int fg = -2;
>
> What's missing in the context here (because it wasn't changed) is:
>
>> if (!strcasecmp(value, "reset")) {
>> strcpy(dst, "\033[m");
>> return;
>> }
>
> which doesn't work, since our string is actually something like
> "reset)\0" or even "reset)some totally unrelated string". So we would
> need a "memcasecmp" here.
if (!strncasecmp(value, "reset", len)) {
> And then in the error case, we call:
>
>> die("bad color value '%s' for variable '%s'", value, var);
>
> which is also bogus.
die("bad color value '%.*s' for variable '%s', len, value, var);
> I don't know if this is really even worth it. The timing difference is
> pretty minimal:
>
> $ time ./git log --pretty=tformat:'%Credfoo%Creset' >/dev/null
> real 0m0.673s
> user 0m0.652s
> sys 0m0.016s
> $ time ./git log --pretty=tformat:'%C(red)foo%C(reset)' >/dev/null
> real 0m0.692s
> user 0m0.660s
> sys 0m0.032s
>
> That's about 1 microsecond per commit.
Hmm, not too much overhead, agreed, but it would still be nice to avoid it.
René
next prev parent reply other threads:[~2009-01-18 17:46 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-16 15:06 [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that Baz
2009-01-17 1:40 ` Jeff King
2009-01-17 12:37 ` Markus Heidelberg
2009-01-17 15:21 ` Jeff King
2009-01-17 15:32 ` [PATCH 1/2] color: make it easier for non-config to parse color specs Jeff King
2009-01-18 17:10 ` René Scharfe
2009-01-18 17:28 ` Jeff King
2009-01-18 17:36 ` Jeff King
2009-01-18 17:45 ` René Scharfe [this message]
2009-01-18 18:06 ` Jeff King
2009-01-17 15:38 ` [PATCH 2/2] expand --pretty=format color options Jeff King
2009-01-18 17:13 ` René Scharfe
2009-01-18 17:37 ` Jeff King
2009-01-18 19:43 ` Jeff King
2009-01-18 19:53 ` Jeff King
2009-01-18 20:37 ` [PATCH 1/2] handle color.ui at a central place Markus Heidelberg
2009-01-18 20:39 ` [PATCH 2/2] move the color variables to color.c Markus Heidelberg
2009-01-20 4:04 ` [PATCH 1/2] handle color.ui at a central place Jeff King
2009-01-21 22:35 ` Markus Heidelberg
2009-01-22 0:00 ` Jeff King
2009-01-22 0:13 ` Markus Heidelberg
2009-01-23 6:13 ` Junio C Hamano
2009-01-24 11:28 ` Markus Heidelberg
2009-01-24 14:14 ` Johannes Schindelin
2009-01-24 14:23 ` Markus Heidelberg
2009-01-24 18:36 ` Junio C Hamano
2009-01-24 19:17 ` Jeff King
2009-01-24 20:26 ` Junio C Hamano
2009-01-24 20:45 ` Jeff King
2009-01-25 14:15 ` Markus Heidelberg
2009-01-19 23:10 ` [PATCH 2/2] expand --pretty=format color options Junio C Hamano
2009-01-20 4:06 ` Jeff King
2009-01-20 10:27 ` Johannes Schindelin
2009-01-20 10:36 ` Johannes Schindelin
2009-01-20 14:23 ` Jeff King
2009-01-20 14:58 ` Johannes Schindelin
2009-01-20 19:21 ` Jeff King
2009-01-17 15:39 ` Cyellow, was Re: [a way-too-long line] Johannes Schindelin
2009-01-17 15:40 ` Jeff King
2009-01-17 15:46 ` Johannes Schindelin
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=49736A9C.1040601@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=markus.heidelberg@web.de \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.