Thread (32 messages) flat view 32 messages, 3 authors, 2016-06-15

Re: [PATCH v4 06/12] ref-filter: introduce color_atom_parser()

From: Karthik Nayak <hidden>
Date: 2016-06-15 23:08:08

On Sun, Feb 7, 2016 at 1:13 PM, Eric Sunshine [off-list ref] wrote:
On Sat, Feb 6, 2016 at 10:20 AM, Karthik Nayak [off-list ref] wrote:
quoted
On Fri, Feb 5, 2016 at 3:55 AM, Eric Sunshine [off-list ref] wrote:
quoted
On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak [off-list ref] wrote:
quoted
+static void color_atom_parser(struct used_atom *atom, const char *color_value)
+{
+       if (!color_value)
+               die(_("expected format: %%(color:<color>)"));
+       if (color_parse(color_value, atom->u.color) < 0)
+               die(_("invalid color value: %s"), atom->u.color);
Shouldn't this be:

    die(_("invalid color value: %s"), color_value);

?
Oops. You're right, it should.
Also the error is reported already in color_parse(...), so seems duplicated.

git for-each-ref  --format="%(color:sfadf)%(align:middle,30)%(refname)%(end)"
error: invalid color value: sfadf
fatal: invalid color value: sfadf

What would be an ideal way around this?
According to f6c5a29 (color_parse: do not mention variable name in
error message, 2014-10-07), the doubled diagnostic messages are
intentional, so I don't think you need to do anything about it in this
series. If you want to make the "fatal" message a bit more helpful,
you could add a %(color:) annotation, like this:

    die(_("unrecognized color: %%(color:%s)"), color_value);

which would give you the slightly more helpful:

    error: invalid color value: sfadf
    fatal: unrecognized color: %(color:sfadf)
That seems to be a good way around the repetitive message.
will add thanks.

-- 
Regards,
Karthik Nayak
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help