All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/5] ref-filter: factor out "%(foo) does not take arguments" errors
Date: Wed, 14 Dec 2022 14:51:33 -0500	[thread overview]
Message-ID: <Y5opRTGtrpoLsSF6@nand.local> (raw)
In-Reply-To: <Y5n3n7Gp2gKNMln3@coredump.intra.peff.net>

On Wed, Dec 14, 2022 at 11:19:43AM -0500, Jeff King wrote:
> Many atom parsers give the same error message, differing only in the
> name of the atom. If we use "%s does not take arguments", that should
> make life easier for translators, as they only need to translate one
> string. And in doing so, we can easily pull it into a helper function to
> make sure they are all using the exact same string.
>
> I've added a basic test here for %(HEAD), just to make sure this code is
> exercised at all in the test suite. We could cover each such atom, but
> the effort-to-reward ratio of trying to maintain an exhaustive list
> doesn't seem worth it.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  ref-filter.c            | 16 +++++++++++-----
>  t/t6300-for-each-ref.sh |  6 ++++++
>  2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/ref-filter.c b/ref-filter.c
> index 08ac5f886e..639b18ab36 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -228,6 +228,12 @@ static int strbuf_addf_ret(struct strbuf *sb, int ret, const char *fmt, ...)
>  	return ret;
>  }
>
> +static int err_no_arg(struct strbuf *sb, const char *name)
> +{
> +	strbuf_addf(sb, _("%%(%s) does not take arguments"), name);
> +	return -1;
> +}
> +

Why introduce such a function? strbuf_addf_ret() already takes a format
string with additional vargs, so it should suffice to replace existing
calls with:

  return strbuf_addf_ret(err, -1, _("%%(%s) does not take arguments"), "objecttype");

Playing devil's advocate for a moment, I suppose arguments in favor of
err_no_arg() might be:

  - It does not require callers to repeat the translation key each time.
  - It requires fewer characters to call.

So I think either is fine, though it might be cleaner to implement
err_no_arg() in terms of strbuf_addf_ret() like:

  static int err_no_arg(struct strbuf *sb, const char *name)
  {
    return strbuf_addf_ret(sb, -1, _("%%(%s) does not take arguments"), name);
  }

Thanks,
Taylor

  reply	other threads:[~2022-12-14 19:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-14 16:18 [PATCH 0/5] minor ref-filter error-reporting bug-fixes Jeff King
2022-12-14 16:18 ` [PATCH 1/5] ref-filter: reject arguments to %(HEAD) Jeff King
2022-12-14 16:19 ` [PATCH 2/5] ref-filter: factor out "%(foo) does not take arguments" errors Jeff King
2022-12-14 19:51   ` Taylor Blau [this message]
2022-12-14 20:03     ` Taylor Blau
2022-12-14 20:28     ` Jeff King
2022-12-14 16:20 ` [PATCH 3/5] ref-filter: factor out "unrecognized %(foo) arg" errors Jeff King
2022-12-14 16:23 ` [PATCH 4/5] ref-filter: truncate atom names in error messages Jeff King
2022-12-14 20:05   ` Taylor Blau
2022-12-14 20:39     ` Jeff King
2022-12-14 16:24 ` [PATCH 5/5] ref-filter: convert email atom parser to use err_bad_arg() Jeff King
2022-12-14 20:05 ` [PATCH 0/5] minor ref-filter error-reporting bug-fixes Taylor Blau

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=Y5opRTGtrpoLsSF6@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --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.